TCP와 UDP? / HTTP 버전

Date:     Updated:

Categories:

Tags: ,

개인적으로 정리한 의견임다!

❓ 네트워크에서의 단어들

  • 프로토콜 -> 네트워크의 통신 규칙
  • 네트워크 아키텍처 -> 프로토콜 여러개를 조합한 것
  • 호스트 -> TCP/IP로 통신하는 각종 네트워크 기기 전반.

❓ 그래서 TCP가 뭔데?

  • 신뢰성 있는 바이트 스트림을 전송하고 받는 것
  • 소켓이라는 종단점을 생성함으로서 이루어짐.
  • 연결 설정
    • 3-way handshake
      image
  • 전이중(전송이 양 방향으로 가능), 점대점(2개의 종단점) 방식.
  • 멀티캐스팅, 브로드캐스팅 미지원
  • 종료
    • 4-way handshake
      image

❓ 그럼 UDP는?

  • 비연결형 프로토콜
  • 흐름제어, 오류제어, 손상세그먼트의 수신에 대한 재전송을 하지 않음
  • 대표적으로 DNS가 있다! (가벼워서)

❓ 그러면 UDP가 아예 신뢰성이 없나?

➔ UDP에서 신뢰성이 없다는 말은 UDP 자체에서 보장하지 않는다는 말이다!
즉슨 개발자가 직접 신뢰성을 보장하도록 할 수 있다!
예) HTTP/3 -> QUIC라는 프로토콜 -> UDP 기반!
즉, UDP 자체는 신뢰성을 보장하지는 않는데, 추가적으로 개발자가 정의를 한다면 신뢰성을 보장받을 수 있다!

그렇다면 HTTP 뒤에 3은 ? 예전 버전부터 알아보자.

❗ HTTP/0.9

버전 번호가 따로 없었던 초기 HTTP는 요청이 단일 라인으로 구성되며 get이 유일한 메서드였다.

# request
GET /index.html

또한 헤더도 없었기 때문에 파일전송은 HTML만 가능했고, 상태코드 또한 존재하지 않았다.

# response
<html>
  index
</html>

❗ HTTP/1.0

기존 0.9를 개선하여 버전번호가 생긴 첫 번째의 HTTP이다. 따라서 이 전 버전은 자연스럽게 0.9가 되었다.

  • request에 버전정보가 붙는다
  • HTTP status가 생겼다!
  • Header 개념이 추가되었다!
# request
GET /index.html HTTP/1.0
User-Agent : ~~~~~~~~~~

# response
200 OK
Date : Tue, 16 Feb 2021 11:05:00 GMT
Server : ~~~~~~~~~~~~
Content-Type : text/html

❗ HTTP/1.1

1.0부터 활성화가 진행되었는데, 얼마 되지 않아 첫 번째 표준버전을 표방한 1.1버전이 발표가 되었다.

  • connection의 지속성 (기존 연결에 대해 handshake를 생략했다)
  • pipelining 추가, 커뮤니케이션 지연을 낮춤.
  • 청크된 응답 조각
  • 캐시 제어 매커니즘
  • 언어, 인코딩 타입을 포함한 컨텐츠 전송
  • 동일 IP주소에 다른 도메인을 Host하는 기능
# request
GET /index.html HTTP/1.1
Host : 127.0.0.1

GET /main HTTP/1.1
Host : google.com
User-Agent : ~~~~
Accept : ~~~~ HTTP/1.1

❗ HTTP/2.0

웹이 발전함에 따라 웹페이지 렌더링 시 필요한 리소스의 수가 크게 늘었다. 동시에 가져올 자원들이 너무 많아진 것이다. 따라서 하나의 웹페이지를 불러오더라고 TCP의 병렬 연결이 필요한 상황이 생겼다. 결국 연결비용이 증가한 것이다.
HTTP/2는 이에서 streams를 도입하였다. 하지만 Head of line Blocking(HOLB) 라는 TCP 패킷이 네트워크 경로에서 손실이 되었을 때 스트림에 공백이 생겨서 발생하는 불필요한 지연 문제가 있었다. TCP에는 어쩔 수 없이 발생하는 문제였다.

특히 HTTP/2.0 에서는 여러개였던 stream을 하나로 묶었기에 더 문제로 다가왔다.

❗ HTTP/3.0

HTTP 3.0 얘기가 나와서 여기까지 흘러왔다. 드디어 대망의 HTTP/3.0이다.
여태와는 다르게 기반 프로토콜이 UDP이다. QUIC !
하지만 UDP라고 해서 신뢰성을 포기한 프로토콜일까? 천만의 말씀!

  • 전달속도 개선
  • 클라이언트와 서버의 연결 수 를 최소화
  • 대역폭을 예상하여 패킷혼잡을 피함

Leave a comment