HTTP 버전별 구분
1. HTTP 0.9
1991년에 처음 도입된 버전으로, 일반 문서만 검색하는 간단한 프로토콜이었다.
초기에는 버전 정보가 없었으나, 이후에 차후 버전과 구별하기 위해 HTTP 0.9라는 이름을 붙이게 되었다.
요청과 응답은 매우 간소했으며, 리소스에 대한 메서드로는 GET이 유일하다.
HTTP 헤더가 없었는데 이는 HTML 파일만 전송될 수 있으며 다른 유형의 문서는 전송될 수 없음을 의미한다.
상태 혹은 오류 코드도 없어서 문제가 발생한 경우, 특정 HTML 파일이 사람이 처리할 수 있도록, 해당 파일 내부에 문제에 대한 설명과 함께 되돌려 보내졌다.
요청과 응답 예시
요청
GET /mypage.html
응답
<HTML>
A very simple HTML page
</HTML>
2. HTTP 1.0
1996년에 출시되었으며, 헤더를 사용하여 이미지와 파일 등 다양한 유형의 콘텐츠를 보내는 기능을 추가했다.
브라우저가 요청에 대한 성공과 실패 여부를 확인할 수 있게 상태 코드의 개념도 도입되었다.
HTTP 헤더 개념은 요청과 응답 모두를 위해 도입되어, 메타데이터 전송을 허용하고 프로토콜을 극도로 유연하고 확장 가능하도록 만들어주었다.
새로운 HTTP 헤더의 도움으로, 평이한 HTML 파일들 외에 다른 문서들을 전송하는 기능이 추가되었다. (Content-Type)
요청과 응답 예시
요청
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
응답
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
<IMG SRC="/myimage.gif">
</HTML>
3. HTTP 1.1
1999년에 발표된 HTTP 1.1은 기존 버전의 문제를 개선하고 성능을 향상했다.
- Keep-Alive 연결
한 번의 TCP 연결을 유지하면서 여러 요청과 응답을 주고받을 수 있도록 한다.
이를 통해 매번 연결을 설정하고 해제하는 오버헤드를 줄여 웹 페이지 로딩 속도를 향상할 수 있다. - 청크 전송 인코딩
데이터를 여러 개의 청크(chunk)로 분할하여 전송하는 방식으로, 데이터의 일부분을 전송하는 동안에도 다른 요청과 응답을 처리할 수 있게 한다. 이를 통해 데이터 전송의 효율성과 성능을 향상할 수 있습니다. - 가상 호스팅(Virtual Hosting)
하나의 웹 서버에서 여러 도메인이나 호스트를 호스팅 할 수 있는 기능이다.
이를 통해 동일한 서버 리소스를 공유하면서도 각각의 도메인이나 호스트에 대한 요청을 구분하여 처리할 수 있다. - 지속적인 연결 관리
HTTP 1.1에서는 지속적인 연결 관리를 위한 헤더들이 추가되었다.
Connection 헤더를 통해 클라이언트와 서버 간의 연결 유지 여부를 지정할 수 있고, Keep-Alive 헤더를 통해 연결을 유지할 시간을 설정할 수 있다.
요청과 응답 예시
요청
GET /example HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: text/html,application/xhtml+xml\
응답
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
<!DOCTYPE html>
<html>
<head>
<title>Example Page</title>
</head>
<body>
<h1>Welcome to the Example Page</h1>
<p>This is an example HTML page.</p>
</body>
</html>
4. HTTP 2.0
HTTP 2.0은 2015년에 출시된 HTTP 프로토콜의 버전 중 하나로, 이전 버전과 비교하여 더욱 효율적이고 성능이 향상된 웹 통신을 제공한다.
- 이진 프레임 형식
HTTP 2.0은 텍스트 프로토콜이라기보다는 이진 프로토콜이다. 그렇기에 더 이상 읽을 수도 없고 수작업을 만들어낼 수 없다.
이런 결점에 대한 보상으로, 새로운 최적화 기술이 구현되어서 데이터 전송을 효율적으로 처리할 수 있다. - 다중화(Mutiplexing)
병렬 요청이 동일한 TCP 커넥션 상에서 다루어질 수 있는 다중화 프로토콜로, 데이터를 병렬로 전송하고, 요청과 응답 간의 의존성을 해결하여 네트워크 지연을 감소시킨다. - 헤더 압축(Header Compression)
전송된 데이터의 분명한 중복과 불필요한 오버헤드를 제거하면서, 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들을 압축시킨다. 이는 대역폭 사용을 최소화하여 성능을 향상한다. - 서버 푸시(Server Push)
서버로 하여금 사전에 클라이언트 캐시를 서버 푸시라고 불리는 메커니즘에 의해, 필요하게 될 데이터로 채워 넣도록 허용한다. 이를 통해 클라이언트의 추가 요청 대기 시간을 줄이고, 페이지 로딩 속도를 향상한다.
이전 HTTP 1.x보다 더욱 효율적이고 성능이 우수한 웹 통신을 제공한다.
동시에 이전 버전과의 하위 호환성을 유지하며, 기존의 웹 애플리케이션과의 호환성을 고려하여 도입되었다.
5. HTTP 3.0
기존의 HTTP/1, HTTP/2와는 다르게 UDP 기반의 프로토콜인 QUIC(Quick UDP Internet Connections)를 사용하여 통신하는 프로토콜이다.
HTTP/3와 기존 HTTP 들과 가장 큰 차이점으로 TCP가 아닌 UDP 기반의 통신을 한다는 것을 들 수 있다.
QUIC는 수정이 어려운 TCP 대신 UDP를 사용함으로써 기능을 확장하였다.
- RTT 감소로 인한 지연시간 단축
QUIC는 TCP가 아닌 UDP를 기반으로 한 프로토콜이기에 3-way Handshake 과정을 거치지 않아도 된다.
TCP+TLS는 통신 시작을 위해 RTT가 3이나 필요함에 비해 QUIC는 연결 설정에 필요한 정보와 함께 데이터도 보내버리기 때문에 첫 연결 설정에 1 RTT만 필요하다.
그뿐만 아니라 나중에 같은 연결이 설정되면 그때는 캐싱해 놓은 설정을 그대로 사용하기에 RTT 없이 바로 통신을 시작할 수 있다. - 패킷 손실 감지에 걸리는 시간 단축
QUIC도 TCP와 마찬가지로 전송하는 패킷에 대한 흐름 제어를 해야 한다. 통신과정에서 발생한 에러를 재전송을 통해 에러를 복구하는 ARQ 방식을 사용하기 때문이다.
QUIC는 TCP와는 달리 패킷마다 고유한 패킷 번호를 부여하여 패킷 손실 감지에 필요한 시간을 단축한다. - 클라이언트의 IP가 변경되어도 연결이 유지됨
기존의 TCP에서는 연결 대상의 IP 주소와 포트 번호를 사용해 연결을 식별하기에 Wi-fi나 셀룰러 변경에 의해 IP가 변경되면 연결이 끊어지게 됐다. 그렇기에 계속 다시 연결을 생성하기 위해 3-way Handshake 과정을 거쳐야만 했다.
반면 QUIC은 Connection ID를 사용하여 서버와 연결을 생성한다. Connection ID는 임의의 값일 뿐, 클라이언트의 IP와는 전혀 무관한 데이터이기 때문에 클라이언트의 IP가 변경되더라도 기존의 연결을 계속 유지할 수 있다.
이는 새로 연결을 생성할 때 거쳐야 하는 핸드쉐이크 과정을 생략할 수 있게 한다.
HTTP vs HTTPS
HTTP와 HTTPS 모두 인터넷에서 데이터를 전송하기 위한 프로토콜이다.
1. HTTP(HyperText Transfer Protocol)
HTTP는 웹 브라우저와 웹 서버 간에 통신하는 데 사용되며, 클라이언트가 서버에게 요청을 보내고 서버가 클라이언트에게 응답을 반환하는 방식으로 작동한다.
주로 HTML 문서, 이미지, 동영상, 파일 등의 정적 및 동적 콘텐츠를 전송하는 데 사용된다. 클라이언트(일반적으로 웹 브라우저)는 URL(Uniform Resource Locator)을 통해 서버에 요청을 보내고, 서버는 요청에 대한 적절한 응답을 생성하여 클라이언트에게 전송한다.
HTTP는 기본적으로 암호화되지 않은 텍스트로 데이터를 전송하기 때문에 보안에 취약하다.
따라서 HTTP는 데이터의 기밀성을 제공하지 않고, 중간에 제3자가 데이터를 가로챌 수 있다.
2. HTTPS(HyperText Transfer Protocol Secure)
HTTP와 동일한 기본 동작 및 구조를 가지며, 데이터를 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 암호화하여 보안을 강화한다.
이를 통해 데이터의 기밀성과 무결성을 보장하며, 중간에 제3자가 데이터를 엿보거나 조작하는 것을 방지한다.
HTTPS의 작동 방식은 다음과 같다.
- 클라이언트는 HTTPS로 액세스 하려는 웹사이트에 연결한다.
- 서버는 클라이언트에게 인증서를 제공한다. 인증서는 웹사이트의 신원을 검증하는 역할을 한다.
- 클라이언트는 서버의 인증서를 확인하고, 인증서의 유효성과 신원을 검증한다. 이를 통해 클라이언트는 웹사이트가 신뢰할 수 있는지를 확인할 수 있다.
- 클라이언트와 서버 간에 암호화된 연결이 설정된다. 클라이언트는 공개키를 사용하여 데이터를 암호화하고, 서버는 개인키를 사용하여 데이터를 해독한다. 이를 통해 데이터의 기밀성을 보장한다.
HTTPS는 인터넷 보안과 사용자 개인 정보 보호를 강화하는 중요한 수단이며, 현대 웹에서는 거의 모든 웹사이트가 HTTPS를 사용하는 것을 권장한다.
TCP 프로토콜의 3-way handshake, 4-way handshake
1. 3-way Handshake
TCP 통신을 이용하여 데이터를 전송하기 위해 네트워크 연결을 설정하는 과정이다.
양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장하고, 실제로 데이터 전달이 시작하기 전에 상대방이 준비되었다는 것을 알 수 있도록 한다.
즉, TCP/IP 프로토콜을 이용해서 통신을 하는 응용 프로그램이 데이터를 전송하기 전에 정확한 전송을 보장하기 위해서 상대방과 사전에 세션을 수립하는 과정을 의미한다.
※ SYN(Synchronization) : 연결요청, 세션을 설정하는 데 사용되며 초기에 시퀀스 번호(SEQ)를 보냄
※ ACK(Acknowledgement) : 보낸 시퀀스 번호에 TCP 계층에서의 길이 또는 양을 더한 것과 같은 값을 ACK에 포함하여 전송
- 클라이언트는 서버에게 TCP 연결 설정 요청을 보낸다. 이를 SYN (Synchronize) 패킷이라고 한다.
- 서버는 SYN 패킷을 받고, 클라이언트로부터의 연결 요청을 수락한다는 의미로 SYN-ACK (Synchronize-Acknowledge) 패킷을 보낸다.
- 클라이언트는 서버로부터의 SYN-ACK 패킷을 받고, 연결을 확인하기 위해 ACK (Acknowledge) 패킷을 서버에게 보낸다.
- 세 개의 패킷을 교환함으로써 클라이언트와 서버 간의 TCP 연결이 설정된다.
2. 4-way Handshake
4-Way Handshake은 TCP 연결을 해제 (Connecntion Termination)하는 과정이다. 여기서는 FIN 플래그를 이용한다.
※ FIN(Finish) : 세션을 종료시키는데 사용되며, 더 이상 보낸 데이터가 없음을 나타낸다.
1. Client → Server : FIN(+ACK)
- 서버와 클라이언트가 연결된 상태에서 클라이언트가 close()를 호출하여 연결 해제 요청
- 클라이언트는 서버에게 연결을 종료한다는 FIN 플래그를 보낸다. => 이때 FIN 패킷에는 실질적으로 ACK도 포함되어 있다.
2. Server → Client : ACK
- 서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보내고 자신의 통신이 끝날 때까지 기다린다. (TIME_WAIT)
=> Server(수신자)는 ACK Number 필드를 (Sequence Number + 1)로 지정하고, ACK 플래그 비트를 1로 설정한 세그먼트를 전송한다. - 서버는 클라이언트에게 응답을 보내고 CLOSE_WAIT 상태에 들어간다. 그리고 아직 남은 데이터가 있다면 마저 전송을 마친 후에 close()를 호출한다.
- 클라이언트에서는 서버에서 ACK를 받은 후에 서버가 남은 데이터 처리를 끝내고 FIN 패킷을 보낼 때까지 기다리게 됩니다. (FIN_WAIT_2)
3. Server → Client : FIN
- 데이터를 모두 보냈다면, 서버는 연결 종료에 합의한다는 의미로 FIN 패킷을 클라이언트에게 보낸 후에, 승인 번호를 보내줄 때까지 기다리는LAST_ACK 상태로 들어간다.
4. Client → Server : ACK
- 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보낸다.
- 아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT을 통해 기다린다.
=> 이때 TIME_WAIT 상태는 의도치 않은 에러로 인해 연결이 데드락으로 빠지는 것을 방지
=> 만약 에러로 인해 종료가 지연되다가 타임이 초과되면 CLOSED로 들어갑니다. - 서버는 ACK를 받은 이후 소켓을 닫는다 (Closed)
- TIME_WAIT 시간이 끝나면 클라이언트도 닫는다 (Closed)
연결 해제의 종류에는 다음의 두 가지 경우가 있다.
Graceful connection release(정상적인 연결 해제)
정상적인 연결 해제에서는 양쪽이 커넥션이 서로 모두 커넥션을 닫을 때까지 연결되어 있다.
Abrupt connection release(갑작스러운 연결 해제)
RST(TCP reset) 세그먼트가 전송되면 갑작스러운 연결 해제가 수행되는데, 다음과 같은 경우에 전송된다.
- 존재하지 않는 TCP 연결에 대해 비SYN 세그먼트가 수신된 경우
- 열린 커넥션에서 잘못된 헤더가 있는 세그먼트가 수신된 경우 - RST 세그먼트를 보내, 해당 커넥션을 닫아 공격을 방지한다.
- 기존 TCP 연결을 종료해야 하는 경우 - 연결을 지원하는 리소스가 부족할 때, 원격 호스트에 연결할 수 없고 응답이 중지되었을 때
TCP Connection 과정
TCP 연결 과정은 위의 그림과 같이 크게 연결 설정(3-way Handshake), 데이터 전송, 연결 종료(4-way Handshake)로 나눌 수 있다.
출처
HTTP의 진화 - HTTP | MDN
HTTP는 월드 와이드 웹에 내재된 프로토콜입니다. Tim Berners-Lee에 의해 1989년부터 1991년에 발명된 HTTP는, 본래의 단순함의 대부분을 지키면서 확장성 위에서 만들어지도록, 많은 수정을 거쳐왔습니
developer.mozilla.org
HTTP/1 부터 HTTP/3 까지 알아보기
성능 관련 이슈 때문에 항상 실무에서 이미지 스프라이트, 도메인 샤딩 등을 적용해왔다. 하지만 드라마틱한 효과는 나타나지 않았고 말로만 들어온 H2적용의 필요성을 느끼게 되어 정리해본다.
velog.io
[네트워크] TCP/UDP와 3 -Way Handshake & 4 -Way Handshake
TCP / UDP / 3-Way Handshake / 4-Way Handshake
velog.io
'개발 > CS' 카테고리의 다른 글
| (CS) git (0) | 2023.07.31 |
|---|---|
| (CS) HTTP Request/Response/Method, CORS, 서브넷 (0) | 2023.05.27 |
| (CS) OSI, TCP/IP Layer, TCP vs UDP (1) | 2023.05.12 |
| (CS) 네트워크 기본 용어 정리 (0) | 2023.05.04 |
| (CS) 단일 연결 리스트 vs 원형 연결 리스트, Stack으로 Queue 구현, 원형 큐 구현 (0) | 2023.04.26 |