프로토콜(Protocol) - HTTP

 

출처 : https://blog.nextinnovation.kr/tech/WebProtocol/

 

프로토콜(Protocol)이란?

통신 프로토콜 또는 통신 규약은 컴퓨터나 원거리 통신 장비 사이에서 메시지를 주고 받는 양식과 규칙의 체계입니다. 즉 프로토콜이란 컴퓨터 네트워크에서 통신을 할 때 지켜야 하는 규칙과 절차의 집합을 말합니다. 다시 말해, 컴퓨터 또는 네트워킹 장비들이 서로 '대화'를 할 때 서로 이해할 수 있도록 '어떻게' 대화해야 하는지에 대한 약속입니다. 이 프로토콜을 통해 데이터의 형식, 신호의 송수신 방법, 데이터의 보정 방법 등 통신의 모든 측면이 정의됩니다.

 

프로토콜의 기본 요소

• 구문(Syntax): 데이터 교환에 사용되는 형식이나 코드를 정의합니다. 다른 매체와 어떤 단위로, 어떤 형식으로, 어떤 신호를 보낼지를 결정합니다. 즉 구문은 전송하고자 하는 데이터의 형식(Format), 부호화(Coding), 신호 레벨(Signal Level) 등을 규정합니다.
  
• 의미(Semantics): 전송되는 정보의 의미와 그에 대한 제어 정보를 정의합니다. 이것은 어떤 작업을 수행할지, 에러가 감지되었을 때 어떤 조치를 취할지 등을 포함합니다.
• 타이밍(Timing): 데이터 흐름의 속도와 데이터 전송과 응답 사이의 시간 간격을 정의합니다. 이는 데이터 전송률을 조절하고, 메시지 간에 필요한 시간 간격을 설정합니다.

 

프로토콜의 종류

프로토콜에는 다양한 유형이 있고, 각각의 목적에 맞게 설계되었습니다. 일반적으로 사용되는 몇가지 프로토콜을 적어보도록 하겠습니다.

 

1. TCP(Transmission Control Protocol): 

• 목적: 신뢰할 수 있는 연결 지향적 데이터 전송을 제공합니다.
• 작동 방식: 데이터를 세그먼트로 분할하고, 순서대로 목적지에 도착하도록 관리합니다. 데이터가 손실되거나 오류가 발생하면 재전송을 요청합니다.
• 사용 예: 웹 브라우징 (HTTP/HTTPS), 이메일 전송 (SMTP), 파일 전송 (FTP)

 

2. IP(Internet Protocol): 

• 목적: 데이터 패킷을 소스에서 목적지까지 전달합니다.
• 작동 방식: 각 데이터 패킷에 소스 및 목적지 주소를 할당하고, 인터넷을 통해 라우팅합니다.
• 사용 예: 거의 모든 인터넷 네트워크 통신에서 사용됩니다.

 

3. HTTP(Hypertext Transfer Protocol): 

• 목적: 웹 서버와 클라이언트 간의 통신을 위한 프로토콜입니다.
• 작동 방식: 클라이언트(브라우저)는 웹 서버에 페이지 요청을 보내고, 서버는 응답을 반환합니다.
• 사용 예: 웹 페이지 로딩, 웹 기반 양식 제출 등

 

4. HTTPS(HTTP Secure): 

• 목적: HTTP에 SSL/TLS 보안 프로토콜을 추가하여 안전한 암호화된 웹 통신을 가능하게 합니다.
• 작동 방식: HTTP 데이터를 SSL 또는 TLS 프로토콜로 암호화합니다.
• 사용 예: 온라인 금융 거래, 개인 정보 보호가 중요한 모든 웹 활동

 

5. FTP(File Transfer Protocol): 

• 목적: 컴퓨터와 서버 간에 파일을 전송하기 위한 프로토콜입니다.
• 작동 방식: 사용자 인증 후, 클라이언트와 서버 간 파일 전송을 허용합니다.
• 사용 예: 웹사이트 파일 관리, 대용량 파일 전송

 

6. SMTP(Simple Mail Transfer Protocol): 

• 목적: 이메일 전송을 위한 프로토콜입니다.
• 작동 방식: 메일 서버 간 이메일 메시지 전송과 사용자가 메일 서버에 이메일을 보내는 과정을 관리합니다.
• 사용 예: 이메일 서비스 제공자에 의한 메일 전송

 

7. IMAP (Internet Message Access Protocol) / POP3 (Post Office Protocol version 3): 

• 목적: 이메일 클라이언트가 서버로부터 메일을 조회하고 다운로드할 수 있도록 하는 프로토콜입니다.
• 작동 방식:
  • IMAP은 서버에 메일을 저장하면서 다양한 클라이언트/장치에서 액세스를 관리합니다.
  • POP3은 메일을 클라이언트로 다운로드하고 서버에서 삭제하는 데 중점을 둡니다.
• 사용 예: 이메일 조회 및 관리

 

8. DNS (Domain Name System): 

• 목적: 사용자가 이해할 수 있는 도메인 이름(예: www.example.com)을 컴퓨터가 이해하는 IP 주소로 변환합니다.
• 작동 방식: 이름 해석을 통해 도메인 이름을 해당하는 IP 주소로 매핑합니다.
• 사용 예: 모든 인터넷 주소 변환 과정

 

 

HTTP 프로토콜

HTTP(Hypertext Transfer Protocol)는 클라이언트와 서버 간의 통신을 위한 Application 계층 프로토콜이며, TCP/IP 위에서 동작합니다.

Web의 데이터 통신의 기반이며, 클라이언트-서버 프로토콜이기도 합니다. 클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미합니다.

주로 HTML 문서, 이미지, 비디오 및 기타 리소스의 전송을 위해 사용됩니다

 

HTTP 기본 개념

• 비연결성: HTTP는 기본적으로 비연결 지향적입니다, 즉 클라이언트가 요청을 하고 서버가 응답을 보낸 후 연결이 바로 종료됩니다. 이는 연결을 유지하는 데 필요한 자원을 절약합니다.
• 무상태성: HTTP는 상태를 유지하지 않습니다. 즉, 서버는 이전의 클라이언트 요청을 기억하지 않습니다. 이 때문에 웹사이트는 쿠키, 세션 등을 이용하여 상태 정보를 유지합니다.
• 확장 가능: HTTP 헤더를 사용하여 기능을 확장할 수 있으며, 사용자 정의 헤더를 추가하여 요청과 응답에 추가 정보를 전송할 수 있습니다.

 

HTTP 요청/응답 모델

HTTP는 클라이언트-서버 프로토콜로, 클라이언트가 서버로 요청을 보내고, 서버는 그 요청에 대한 응답을 반환합니다. 요청과 응답은 모두 메시지 형태로 이루어지며, HTTP 헤더(Header)와 바디(Body)를 포함할 수 있습니다.

 

 

HTTP 메서드

HTTP 메서드는 클라이언트가 수행하고자 하는 동작을 정의합니다.

• GET: 서버로부터 정보를 조회하기 위해 사용됩니다.
• POST: 서버에 데이터를 전송하기 위해 사용됩니다.
• PUT: 지정된 URI에 대해 새로운 내용을 만들거나, 이미 있는 내용을 대체하기 위해 사용됩니다.
• DELETE: 지정된 URI의 리소스를 삭제하기 위해 사용됩니다.
• PATCH: 리소스의 일부분만을 업데이트하기 위해 사용됩니다.
• HEAD: 리소스의 헤더 정보만 가져오기 위해 사용됩니다.
• OPTIONS: 해당 서버의 통신 옵션을 조회하기 위해 사용됩니다.

 

 

HTTP 메서드 GET과 POST의 차이

GET 메서드는 데이터를 조회하는 데 사용되며, 데이터가 URL의 일부분(쿼리 스트링:Query String)으로 전송됩니다. 

POST 메서드는 데이터를 서버로 보낼 때 사용되며, 데이터가 요청의 바디(Request Body)에 포함되어 서버로 전송됩니다.

 

HTTP 메서드 PUT과 PATCH의 차이

PUT과 PATCH는 모두 리소스를 업데이트하는 데 사용되지만,

PUT은 리소스 전체를 교체하는데 사용되고,

PATCH는 부분적인 변경을 할 때 사용됩니다.

 

 

HTTP 상태 코드

HTTP 상태 코드는 서버가 클라이언트의 HTTP 요청을 어떻게 처리했는지를 나타내는 3자리 숫자 코드입니다. 이 코드들은 다섯 가지 클래스로 분류됩니다.

1. 1xx (정보 응답): 요청을 받았고 프로세스를 계속 진행한다는 것을 나타냅니다.
   • 100 Continue: 초기의 요청이 받아들여졌고 클라이언트는 요청을 계속할 수 있음을 나타냅니다.
   • 101 Switching Protocols: 서버가 클라이언트가 요청한 프로토콜 전환을 승인했음을 나타냅니다.
2. 2xx (성공): 클라이언트의 요청이 성공적으로 받아들여졌고 이해되었으며 처리되었다는 것을 나타냅니다.
   • 200 OK: 요청이 성공적으로 처리됨.
   • 201 Created: 요청이 성공적으로 이행되었고 새로운 리소스가 생성됨.
   • 204 No Content: 요청이 성공적으로 이행되었으나 전송할 컨텐츠가 없음.
3. 3xx (리다이렉션): 추가 작업이 필요하다는 것을 나타냅니다.
   • 301 Moved Permanently: 요청한 페이지가 새 위치로 영구적으로 이동되었습니다.
   • 302 Found: 요청한 페이지가 일시적인 새 위치로 이동되었습니다.
   • 304 Not Modified: 조건부 GET 요청에 대해 리소스가 수정되지 않았을 때 사용됩니다.
4. 4xx (클라이언트 오류): 클라이언트의 잘못된 요청이나 처리 불가능한 요청을 나타냅니다.
   • 400 Bad Request: 서버가 요청을 처리할 수 없도록 만드는 잘못된 문법 때문에 서버가 요청을 이해할 수 없음.
   • 401 Unauthorized: 현재 요청이 인증이 필요함.
   • 403 Forbidden: 서버가 요청을 이해했지만 승인을 거부함.
   • 404 Not Found: 서버가 요청한 리소스를 찾을 수 없음.
5. 5xx (서버 오류): 서버가 유효한 요청을 처리하지 못했다는 것을 나타냅니다.
   • 500 Internal Server Error: 서버 내부 오류로 요청을 수행할 수 없음.
   • 501 Not Implemented: 서버가 요청 메서드를 지원하지 않거나 처리할 수 없음.
   • 503 Service Unavailable: 서버가 일시적으로 서비스를 제공할 수 없음(과부하 또는 유지 보수로 인해).

 

 

HTTP 헤더(Header)

HTTP 헤더는 클라이언트와 서버 사이의 요청과 응답에 대한 추가 정보를 제공합니다.

HTTP 헤더는 HTTP 요청과 응답 메시지의 일부로, 서버와 클라이언트 간에 전송되는 다양한 유형의 메타데이터를 포함합니다. 여기에는 요청이나 응답의 컨텍스트를 설명하거나, 메시지의 내용을 설명하거나, 애플리케이션 작동 방식에 대한 지시를 담은 정보가 포함됩니다.

 

Host: 
Host 헤더는 요청이 전송되는 대상 서버의 도메인 이름과 포트 번호를 포함합니다. 이 헤더는 특히 하나의 IP 주소에 여러 도메인이 호스팅되고 있는 경우(이를 가상 호스팅이라 함) 서버가 어떤 웹사이트를 반환할지 결정하는 데 중요합니다. HTTP/1.1 부터는 Host 헤더가 필수입니다.
ex) Host: http://www.example.com

 

Authorization: 
Authorization 헤더는 클라이언트가 서버에 접근할 때 필요한 인증 자격증명을 포함합니다. 보통 Base64 인코딩 방식으로 인코딩된

{ID : 비밀번호} 쌍을 포함하거나, 토큰 기반 인증에 사용됩니다.

 

Content-Type: 
Content-Type 헤더는 HTTP 메시지 바디의 미디어 타입을 나타냅니다. 서버와 클라이언트는 이 정보를 사용하여 데이터를 올바르게 해석하고 처리할 수 있습니다. 예를 들어, 웹 폼을 통해 데이터가 전송되면 Content-Type은 application/x-www-form-urlencoded 또는 multipart/form-data가 될 수 있고, JSON을 통해 데이터를 전송할 때는 application/json으로 설정됩니다.
ex) Content-Type: application/json

 

 

HTTP의 무상태성(Stateless)

HTTP의 무상태성(Statelessness)은 프로토콜이 이전에 수행된 요청과 응답 사이의 정보를 기억하지 않는다는 것을 의미합니다. 다시 말해, 각 HTTP 요청은 독립적이며 이전 요청의 데이터를 포함하지 않습니다. 이러한 특성 때문에 서버는 각 요청을 새로운 거래로 처리해야 하며, 요청 사이에 클라이언트의 상태를 유지하지 않습니다.

HTTP 무상태성의 장점

1. 단순성: 서버는 각 요청을 처리하기 위해 이전 상태를 추적하거나 저장할 필요가 없으므로 구현이 단순해집니다.
2. 확장성: 상태 정보가 없으므로 서버는 요청을 더 쉽게 분산시킬 수 있고, 부하 분산과 서버의 확장이 용이합니다.
3. 독립성: 각 요청이 독립적이므로, 개별 요청이 실패하더라도 전체 시스템에 영향을 미치지 않습니다.

 

HTTP 무상태성의 단점

1. 상태 유지의 어려움: 로그인 상태, 쇼핑 카트 정보 등 사용자 세션과 관련된 데이터를 유지하려면 별도의 메커니즘이 필요합니다.
2. 효율성 저하: 클라이언트는 상태를 유지하기 위해 매 요청마다 필요한 모든 정보를 재전송해야 할 수도 있습니다.

 

상태 유지를 위한 기술

1. 쿠키(Cookies): 서버가 클라이언트에게 작은 데이터 조각을 저장하도록 하여, 후속 요청에 클라이언트가 해당 데이터를 반환함으로써 사용자 상태를 유지할 수 있게 합니다. 저장된 정보를 다른 사람 또는 시스템이 볼 수 있는 단점이 있으며, 유효시간이 지나면 사라집니다.
2. 세션(Session): 쿠키를 사용하여 고유한 세션 식별자를 클라이언트에게 제공하고, 이를 통해 서버는 사용자의 상태 정보를 서버측에서 관리합니다. 서버가 종료되거나 유효시간이 지나면 사라집니다.

 

HTTP Keep-Alive

HTTP Keep-Alive, 공식적으로는 "Persistent Connection"이라고 불리는 기능은 HTTP 통신에서 한 번의 TCP 연결을 통해 여러 HTTP 요청/응답 교환을 가능하게 하는 기입니다. 이 기능은 HTTP/1.0에서 선택적으로, HTTP/1.1에서 기본 설정으로 사용됩니다.

 

출처 : https://jins-dev.tistory.com/entry/HTTP11-%EC%9D%98-HTTP-Pipelining-%EA%B3%BC-Persistent-Connection-%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC

 

HTTP/1.0에서는 클라이언트가 서버에 요청을 보낼 때마다 TCP 연결을 새로 맺고, 응답을 받은 후 연결을 닫는 방식입니다. 이는 각 요청마다 새로운 연결 설정에 대한 오버헤드가 발생한다는 단점이 있습니다. 이러한 단점을 해결한 것이 HTTP/1.1 입니다. HTTP/1.1에서는 기본적으로 Keep-Alive가 활성화 되어 있으며, 필요하지 않을 시에 따로 설정을 해주는 방식으로 변경되었습니다.

 

HTTP Keep-Alive가 활성화되어 있으면, 클라이언트와 서버는 HTTP 응답 후에도 TCP 연결을 닫지 않고 유지합니다. 이를 통해 클라이언트는 추가적인 HTTP 요청을 동일한 연결을 통해 보낼 수 있으며, 여러 리소스를 요청할 때 연결 설정과 해제에 대한 오버헤드를 감소시킵니다.

 

HTTP Keep-Alive의 장점

1. 통신 속도 향상: 연결 설정에 소요되는 시간을 줄여 전체 통신 속도가 향상됩니다.
2. 네트워크 과부하 감소: 지속적인 연결을 통해 네트워크의 연결 및 해제 요청이 감소하여 네트워크 부하를 줄일 수 있습니다.
3. 서버 부하 감소: 서버는 연결을 재사용하기 때문에 새로운 연결에 대한 자원 할당과 해제 과정이 줄어듭니다.

 

HTTP Keep-Alive의 단점

1. 서버 자원 사용: 지속적 연결은 사용되지 않을 때에도 서버의 자원을 계속 사용하게 되므로, 많은 수의 클라이언트가 서버에 연결되어 있을 때 서버 자원에 대한 압박이 증가할 수 있습니다.
2. 타임아웃 관리 필요: 서버와 클라이언트는 연결이 더 이상 필요하지 않을 때 적절한 시점에 연결을 닫기 위한 타임아웃 정책을 관리해야 합니다.

 

 

HTTP 파이프라이닝

HTTP 파이프라이닝은 클라이언트가 서버로부터 응답을 받기를 기다리지 않고 여러 개의 HTTP 요청을 연속적으로 전송할 수 있게 하는 통신 기법입니다. 이 방식은 클라이언트가 요청의 결과를 기다리는 시간을 줄이려는 목적으로 설계되었습니다. HTTP 파이프라이닝은 HTTP/1.1 프로토콜에서 도입된 기능입니다.

 

출처 : https://jins-dev.tistory.com/entry/HTTP11-%EC%9D%98-HTTP-Pipelining-%EA%B3%BC-Persistent-Connection-%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC

 

기존의 HTTP/1.0에서는 각 요청에 대해 응답을 받기 전까지 새로운 요청을 보낼 수 없었습니다. 즉, 클라이언트가 요청을 하면 서버로부터 그 요청에 대한 응답을 완전히 받은 후에야 다음 요청을 보낼 수 있었습니다. 이러한 통신 방식은 "회전 지연(round-trip delay)"이라고 불리는 네트워크 지연을 일으키며, 연결의 사용률을 낮추는 원인이 됩니다.

HTTP/1.1의 파이프라이닝을 사용하면, 클라이언트는 여러 개의 HTTP 요청을 보낼 수 있고, 서버는 이러한 요청들을 받아 순서대로 처리합니다. 서버는 요청을 받은 순서에 따라 응답을 구성하지만, 응답은 필히 요청 순서대로 보내야 하므로, 첫 번째 요청에 대한 응답을 구성하는 데 시간이 걸리면 그 다음 요청에 대한 응답도 지연될 수 있습니다. 이를 "헤드 오브 라인 블로킹(head-of-line blocking)" 문제라고 합니다.

 

파이프라이닝의 동작 과정:

1. 클라이언트 요청: 클라이언트가 서버에 첫 번째 요청을 보냅니다.
2. 연속 요청 전송: 첫 번째 요청의 응답을 기다리지 않고 클라이언트는 추가적인 HTTP 요청을 바로 전송합니다.
3. 서버 수신과 처리: 서버는 받은 요청을 순차적으로 처리합니다. 요청은 FIFO(First In First Out) 방식으로 관리됩니다.
4. 응답의 순차적 전송: 서버는 요청을 받은 순서대로 응답합니다. 이 때, 첫 번째 요청에 대한 처리가 끝나기 전까지는 다음 응답을 전송할 수 없습니다.
5. 클라이언트 수신: 클라이언트는 서버로부터 응답을 순차적으로 받습니다.

 

HTTP 파이프라이닝의 주요 문제점:

• 헤드 오브 라인 블로킹: 첫 번째 요청의 처리가 지연되면 모든 응답이 지연됩니다.
• 응답의 순서: 서버는 요청받은 순서대로 응답을 보내야 하기 때문에, 중간에 어떤 요청의 처리가 빠르게 완료되어도, 그 앞에 있는 요청의 응답이 완료되기 전까지는 보낼 수 없습니다.
• 복잡한 서버 관리: 서버는 파이프라인으로 처리할 요청들을 모두 올바른 순서로 관리하고 응답해야 하므로, 서버의 부담이 커집니다.
• 구현의 어려움: 모든 클라이언트와 서버가 HTTP 파이프라이닝을 제대로 지원하고 구현해야만 이 기능이 제대로 작동합니다.

 

 

HTTP/1.1, HTTP/2, HTTP/3

• HTTP/1.1:  
  • 하나의 TCP 연결에 대해 하나의 요청/응답 처리를 진행하며, Keep-Alive를 통해 연결을 재사용합니다.
  • Keep-Alive(Persistent Connection) 지원
  • Pipelining 기술 지원
  • 연결당 하나의 요청과 응답을 처리하기 때문에 동시 전송 문제가 발생하여 속도가 느리고 성능이 좋지 않습니다.
  • Head Of Line Blocking 문제 발생

 

• HTTP/2: 
  • HTTP/1.1의 성능 문제를 해결하기 위한 것으로, SPDY 프로토콜을 기반으로 개발되었습니다.
  • 단일 TCP 연결을 통해 여러 요청과 응답을 비동기 방식으로 처리할 수 있게 하며, 헤더 압축 등의 기능을 도입했습니다.
  • 스트림 멀티플렉싱(Multiplexing) : 단일 TCP 연결을 통해 여러 개의 메시지를 동시에 주고받을 수 있어서 동시성을 대폭 향상시켰고, 헤드 오브 라인 블로킹 문제를 완화했습니다.
  • 우선순위 지정(Stream Prioritization): 클라이언트가 요청에 우선순위를 지정할 수 있어, 중요한 요청부터 빠르게 처리될 수 있습니다.
  • 서버 푸시(Server Push): 서버가 클라이언트의 요청을 예측하고 필요한 리소스를 미리 클라이언트에게 보낼 수 있습니다.
  • 헤더 압축(Header Compression): 헤더 필드를 압축하여 중복 데이터 전송을 줄이고 전체적인 통신 효율을 개선했습니다.

 

• HTTP/3:
  • HTTP/3는 현재 개발 중인 HTTP 프로토콜의 최신 버전입니다. 이는 UDP 기반의 QUIC 프로토콜 위에서 작동하며, 기존의 TCP 기반 HTTP 버전들의 몇 가지 문제를 해결하기 위해 개발되었습니다.
  • QUIC 프로토콜 사용: QUIC는 연결 설정 시간을 줄이고, 개선된 전송 신뢰성과 성능을 제공합니다.
  • 빠른 연결 복구: 패킷 손실 발생 시 TCP보다 빠르게 회복합니다.
  • 내장된 암호화: QUIC 프로토콜 내부에 기본적으로 TLS 암호화를 내장하고 있어 보안이 강화되었습니다.
  • 스트림과 헤드 오브 라인 블로킹의 분리: 개별 스트림이 독립적으로 처리되므로, 한 스트림의 지연이 다른 스트림에 영향을 주지 않습니다.

 

 

 

참고자료

 

Web Protocols

[Network] 프로토콜(Protocol)이란? (What is a protocol?)

HTTP 개요 - HTTP | MDN

상태유지기술 (Cookie & Session)

HTTP Header의 구조와 주요 정보: 웹 서비스 이해하기

[HTTP] keep alive란? (persistent connection에 대하여)

[Network 04] Persistent Connection을 위한 기술 01 - Keep Alive (TCP, HTTP)

HTTP/1.1 의 HTTP Pipelining 과 Persistent Connection 에 대하여

HTTP/1.1, HTTP/2, HTTP/3