HTTP

1. HTTP란?

HyperText Transfer Protocol
서버와 클라이언트 간의 TCP/IP 통신 위에서 리소스를 교환하기 위해 사용되는 프로토콜.

• 프로토콜 : 서로 다른 하드웨어 기기 간의 데이터 통신 규약.
• 리소스 : 웹에서 요청할 수 있는 정보나 객체, 문서, 이미지, 비디오, 오디오 등 다양한 형태의 콘텐츠로 구성.

2. HTTP 구성요소

HTTP는 클라이언트-서버 프로토콜

• 클라이언트(Client): 웹 브라우저, 앱, 또는 웹 서비스와 같은 HTTP 클라이언트는 사용자에게 인터페이스를 제공하며, 웹 서버에 리소스 요청을 보냄.
• 서버(Server): 웹 서버는 클라이언트로부터 요청을 받아 처리한 후, 요청한 리소스와 함께 응답을 반환.
• 프록시(Proxy) : 클라이언트와 서버 사이에서 중개자 역할을 수행하는 서버, 보안, 캐싱, 로드 밸런싱 등의 기능을 제공.

👀 프록시의 역할

1. 캐싱: 클라이언트의 요청을 캐시에 저장하고, 같은 요청이 들어올 때 직접 응답을 반환함으로써 서버의 부하를 줄이고 응답 시간을 개선.
2. 로드 밸런싱: 여러 서버들이 서로 다른 요청을 처리하도록 허용, 전체 시스템의 성능과 안정성을 향상시킵니다.
3. 보안 : 방화벽 역할을 수행하여, 보안 위험을 최소화.
4. 인증 : 다양한 리소스에 대한 접근 제어.

3. stateless한 HTTP

• 서버는 클라이언트의 이전 요청에 대한 정보를 기억하지 않기 때문에 각각의 요청은 서로 독립적으로 처리.
• 성능 및 확장성 면에서 이점을 제공.
• 사용자 인증이나 세션 관리와 같은 상태 정보를 유지해야 하는 상황에서는 추가적인 구현이 필요.-> 쿠키, 세션

👀 상태 정보를 유지하기 위한 쿠키와 세션

쿠키(Cookie)

1. 클라이언트 측에 저장되는 작은 데이터 조각, 서버는 쿠키를 통해 클라이언트의 상태 정보를 기억.
2. 로그인 상태, 선호 설정, 장바구니 정보 등을 저장하는 데 사용.
3. 보안에 취약할 수 있고 사용자의 컴퓨터에 저장되기 때문에 저장 공간에 제한이 있음.

세션(Session)

1. 서버 측에서 클라이언트의 상태 정보를 관리.
2. 세션 ID를 통해 클라이언트 정보를 구분하고 서버에 저장.
3. 보안상 중요한 정보나 대량의 데이터를 저장하는 데 사용.
4. 서버의 자원을 사용하기 때문에, 사용자가 많을 경우 서버에 부담.

4. 클라이언트와 서버와 통신과정

1. 사용자가 웹 브라우저에서 웹 페이지를 요청하면, HTTP 프로토콜을 통해 요청 메시지를 생성한다.
2. 요청 메시지는 TCP/IP 프로토콜을 거쳐 데이터 패킷으로 변환된다. 이 과정에서 전송 계층의 TCP 프로토콜이 데이터를 순차적으로 전달하고 신뢰성을 보장.
3. 데이터 패킷은 네트워크 계층의 IP 프로토콜을 사용하여 인터넷을 통해 웹 서버로 전송된다.
4. 웹 서버는 데이터 패킷을 받아 TCP/IP 프로토콜 스택의 계층을 거쳐 원래의 요청 메시지로 변환한다.
5. 웹 서버는 요청에 따른 적절한 웹 페이지를 찾아 HTTP 응답 메시지를 생성하고, 이 과정을 거꾸로 반복하여 사용자에게 전달한다.

• HTTP는 웹 페이지 요청과 응답을 처리하고, TCP/IP는 데이터 패킷을 안전하고 순차적으로 전달하는 역할.
• TCP는 장치들 사이에 논리적 접속 성립(establish)을 위해 3-way Handshake를 사용
• 3-way Handshake : 클라이언트와 서버 간 데이터 전송 준비가 되었음을 확인하는 과정

👀 DNS

Domain Name System

• 컴퓨터는 숫자로 된 IP 주소를 사용하여 서로를 찾지만, 사람들은 이 숫자들을 기억하기 어렵기 때문에 도메인 이름(예: www.example.com)을 사용.
• 웹 브라우저에 URL이나 URI를 입력하면, DNS 서버가 해당 도메인 이름을 IP 주소로 변환하여 사용자를 올바른 웹 서버에 연결
• URI : 리소스 식별자, URL(Uniform Resource Locator), URN(Uniform Resource Name)을 포괄하는 개념
• URL : 리소스 위치를 나타내는 고유한 주소, 특정 프로토콜(http, https 등), 도메인 이름, 파일 경로 등으로 구성.

5. HTTP 메서드

1. GET
   • 정보를 요청하기 위해 사용.
   • 캐싱을 통해 동일한 요청을 보내도 항상 같은 응답.(멱등성 O)
   • 캐시를 사용하고 브라우저 기록이 남음.
   • 성공시 200 응답코드.
   • URL에 데이터가 노출되므로 보안에 취약.
2. POST
   • 새로운 리소스을 생성하기 위해 사용.
   • 캐시되지 않고 브라우저 기록이 남지 않음.
   • 자원 생성은 201(Created) HTTP 응답 코드를 반환.
   • 멱등성 X
3. PUT
   • 기존 리소스를 수정하기 위해 사용.
   • 동일한 요청을 여러 번 보내도 항상 같은 결과.(멱등성 O)
   • 해당 자원이 없는 경우, 새로운 자원을 생성.
4. PATCH
   • 기존 리소스의 일부분을 수정하기 위해 사용.
   • 동일한 요청을 여러 번 보내면 서로 다른 결과를 받을 수 있음(멱등성 X).
   • 해당 자원이 없는 경우, 새로운 자원을 생성하지 않음.
5. DELETE
   - 리소스를 삭제하기 위해 사용.
   - 요청된 데이터가 body에 포함되지 않으며, URL에 자원 식별자가 포함.
   - 동일한 요청을 여러 번 보내도 항상 같은 결과.(멱등성 O)
   됩니다.
6. HEAD
   • GET과 동일한 요청을 하지만, 서버는 응답 본문을 포함하지 않고 응답 헤더만을 반환.
   • 주로 웹사이트의 상태를 체크하기 위해 사용
7. OPTIONS
   • 서버가 허용하는 메서드, 인증 요구사항 등을 확인하기 위해 사용

• 멱등성(Idempotent) : HTTP에서 멱등성이란 동일한 요청을 여러 번 보내도 요청 서버의 상태나 리소스의 상태가 항상 동일한 것.(헷갈림 주의! 요청을 했을 때 기존 리소스의 변경 유무와는 다르다. 멱등성은 여러번 요청을 해도 같은 결과가 나오는 것!)

PUT과 PATCH의 멱등성 차이
PUT 요청에서는 객체 {name: "John", age: 30}를 전체적으로 대체하는 목적으로 사용됩니다. 그리고, 클라이언트가 동일한 데이터 {name: "John", age: 30}를 요청 본문으로 보낸 PUT 요청을 여러 번 보내면, 서버에서는 해당 객체를 항상 {name: "John", age: 30}로 수정하게 됩니다. 이는 멱등성을 보장하는 것입니다.

반면, PATCH 요청에서는 객체 {name: "John", age: 30}의 일부 속성만을 수정하는 목적으로 사용됩니다. 예를 들어, 클라이언트가 PATCH 요청으로 객체의 name 속성만 "Tom"으로 수정하는 요청을 보낸 경우, 해당 객체는 {name: "Tom", age: 30}으로 수정됩니다. 그리고, 클라이언트가 동일한 데이터 {name: "Tom", age: 30}를 요청 본문으로 보낸 PATCH 요청을 여러 번 보내도, 서버에서는 해당 객체를 {name: "Tom", age: 30}으로 수정하게 됩니다. 그러나, 만약 클라이언트가 PATCH 요청으로 객체의 age 속성만 31로 수정하는 요청을 보낸 경우, 해당 객체는 {name: "John", age: 31}으로 수정됩니다. 따라서, 클라이언트가 동일한 데이터 {name: "John", age: 30}를 요청 본문으로 보낸 PATCH 요청을 여러 번 보내도, 서버에서는 해당 객체를 항상 동일한 상태로 수정할 수 없으므로, 멱등성을 보장하지 않는 것입니다.

6. HTTP/1.0, 1.1, 2.0

1. HTTP/1.0
   • 1996년에 첫 번째로 발표된 HTTP 버전으로, 간단한 요청-응답 메커니즘.
   • 연결당 하나의 요청과 응답을 처리하며, 각 요청 후에 연결이 종료되어 웹페이지 로딩이 느린 문제 발생.
2. HTTP/1.1
   • 1997년에 발표되어, 웹의 효율성과 성능을 개선하기 위한 기능 추가.
   • 지속적인 연결을 도입하여 여러 요청을 처리할 수 있음.
   • 하지만 현재 요청이 오래걸리면 그 다음 요청들의 처리가 늦어지는 문제 발생.
3. HTTP/2.0
   • 2015년에 발표, 웹의 성능을 더욱 개선.
   • 다중화를 도입하여, 하나의 연결에서 동시에 여러 요청-응답을 처리.
   • 헤더 압축 기능으로, 데이터 교환을 더욱 효율적으로 수행

7. HTTP vs HTTPS

• HTTP는 도청이 가능하며(TCP/IP) 통신 상대를 확인하지 않아 신뢰성이 떨어짐. (응답, 요청하는 클라이언트와 서버에 대해 확신할 수 없음)
• HTTPS는 SSL을 이용해 데이터를 암호화하고 보안성을 보장.
• SSL : 암호화 기반 인터넷 보안 프로토콜.
• Google 검색 알고리즘에서 HTTPS를 사용하는 웹사이트의 랭킹을 더 높게 부여하기 때문에 검색엔진 최적화(SEO)에도 도움

[youtube] 큰돌의터전_[HTTP1과 HTTP2 그리고 HTTP3]
[youtube] 우아한테크_[10분 테코톡] 헌치, 써머의 HTTP
[youtube] Code ON 코드온_HTTP와 HTTPS 차이점 (현업에 적용하는 CS 5탄)
[mozila] HTTP