Socket과 Port의 특징, HTTP 버전 별 정리

Socket(소켓)

소켓이란 네트워크 상에서 동작하는 프로그램 간 통신의 종착점(Endpoint)이다. 즉, 프로그램이 네트워크에서 데이터를 통신할 수 있도록 연결해주는 연결부라고 볼 수 있다. 데이터를 통신할 수 있도록 연결해주기 때문에 통신할 클라이언트와 서버 모두에 소켓이 생성되어야 한다.

* Endpoint : IP 주소와 Port 번호의 조합을 뜻하며 최종 목적지 역할을 한다.

.ibm.com/docs

클라이언트가 소켓 호출하면, 클라이언트의 응용 프로그램과 서버의 응용 프로그램 간에 소켓 연결이 설정된다.

상황을 이해하기 쉽게 '전화'로 비유해보면,

1) 전화기에서 전화번호로 전화를 거는 것 = 소켓 호출을 시작
2) 전화 교환 장치는 통화를 완료하기 위해 논리적으로 올바른 교환 위치를 알고 있음
3) 전화 대화 중에 연결되어 정보가 교환됨
4) 전화를 끊으면 연결이 끊어지고 다시 시작해야함
5) 클라이언트는 socket() 함수 호출을 사용하여 서버에 연결 

Socket을 통한 연결 과정

Server는 특정 포트와 연결된 소켓을 가지고 컴퓨터 위에서 동작한다. 이 서버는 소켓으로 클라이언트의 연결 요청이 있을 때까지 기다린다. Client 소켓에서 연결 요청을 하면 서버 소켓이 허락을 하여 통신을 할 수 있도록 연결된다.

프로세스마다 고유한 포트번호를 가지고 있으며, 여러개의 소켓을 가질 수 있다. 포트번호에서 보여진 정보인 ip 주소와 프로토콜 정보, 포트번호를 통해서 소켓은 생성될 소켓의 종류를 결정하여 프로세스에 맞게 생성되었다가 통신이 종료되면 소켓을 삭제한다.

Port(포트)

한 PC에는 다양한 프로그램들이 프로세스 단위로 실행되는데, 각 프로그램을 식별할 수 있는 번호가 Port다. 네트워크를 통해서 데이터를 주고 받을 때 어떤 프로세스가 어떤 프로세스에게 보내는 데이터인지 정보를 확인하는 용도로 사용된다.

Socket과 Port의 차이

- 소켓은 특정 포트에서 데이터를 송수신하는 인터페이스, 포트는 장치의 특정 프로세스 또는 프로그램에 할당된 숫자 값이다.

- 소켓은 컴퓨터 네트워크의 노드 내에서 데이터를 보내고 받기 위한 내부 Endpoint, 포트는 통신의 Endpoint에서 응용 프로그램에 할당되는 숫자 값이다.

- 소켓이 특정 포트를 통해 데이터를 주고받는 인터페이스 역할, 포트는 특정 어플리케이션이나 프로세스를 식별하는데 도움을 준다.

---

HTTP 버전 정리

HTTP 0.9 (원라인 프로토콜)

HTTP 초기 버전에는 버전 번호가 없었다. HTTP/0.9 이후에 버전 구별을 위해 0.9라 불리게 되었다. HTTP/0.9는 아주 단순한 것으로, 요청은 단일 라인으로 구성되어 리소스에 대한 경로로 가능한 메소드는 'GET'이 유일했다.

특히 HTTP Header가 없이 HTML 파일만 전송이 가능했으며, 다른 유형의 문서는 전송이 불가능했다. 흔히 있는 상태코드, 에러 코드도 없었다.

HTTP 1.0 (확장성 증가)

기존 0.9에서 브라우저와 서버가 더 높은 유연성을 위해 개선되었다.

- 버전 정보가 각 요청 사이로 전송이 시작 (HTTP/1.0이 GET 라인에 붙음)
- 상태 코드 라인이 응답의 시작 부분에 붙어 전송되어 요청에 대한 성패를 확인할 수 있게 되었다.
- HTTP 헤더의 개념이 요청과 응답에 도입되어, 메타데이터 전송이 가능하였으며, 프로토콜을 아주 유연하고 확장할 수 있도록 만들었다.
- HTML 파일 외에 다른 문서들을 전송하는 기능이 추가되었다. 

HTTP 1.1 (표준 프로토콜)

HTTP 1.1은 HTTP 1.0이 나온지 몇달안되어 1997년에 공개되었다. 기존 1.0의 모호한 부분을 개선하여 여러 기능이 추가되었다.

- 커넥션이 재사용할 수 있게되었다. 탐색된 단일 원본 문서 내로 임베드된 리소스들을 디스플레이하기 위해 사용된 커넥션을 다시 열어 시간을 절약할 수 있게되었다.
- 파이프라이닝이 추가되었다. 첫번째 요청에 대한 응답이 완전히 전송되기 전에 두번째 요청 전송을 가능케하여 커뮤니케이션의 지연시간을 낮췄다.
- 분할된(Chunk) Request를 보내는게 가능해졌다.
- 캐시 제어 매커니즘이 도입되었다.
- 언어, 인코딩, 타입을 포함한 컨텐츠 협상이 가능해져, 클라이언트와 서버의 교환에서 최적의 컨텐츠를 선택할 수 있게되었다.
- Host 헤더 덕분에 동일 IP 주소에 다른 도메인을 호스트하는 기능이 가능하게 되었다. 

HTTP 2 (더 나은 성능을 위한 프로토콜)

인터넷의 발전에 따라 표시되는 미디어와 상호작용을 위한 스크립트의 양과 크기가 더 많이 증가하였다. HTTP 1.1은 순서대로 전송되는 요청을 필요로하여 병목현상과 복잡도 문제가 있다. 

2010년, Google은 SPDY 프로토콜을 구현하여 클라이언트와 서버 간의 데이터 교환을 대체할 수단을 실증하였다. SPDY는 HTTP 2 프로토콜의 기초 토대가 되었다.

header와 content를 각각 하나의 프레임으로 분리.

- Text protocol이 아니라, Binary Protocol이다. 수동으로 읽거나 만들어질 수 없다. 그러나 이를 통해서 최적화 기술을 구현할 수 있게 되었다.

1, 3, 5 스트림 총 3개가 동시에 병렬적으로 하나의 연결안에서 이루어진다.

- 다중화된 프로토콜이다. 응답의 다중화(멀티플렉싱)을 통해서 여러개의 연결없이도 병렬 요청을 수행할 수 있다.
- 헤더를 압축한다. 유사한 요청이 많기 때문에 전송된 데이터의 중복, 오버헤드를 제거한다
- 서버는 'Server push' 라는 매커니즘을 통해 클라이언트 캐시에 데이터를 채울 수 있게된다.

2015년 5월 공식적으로 표준화된 HTTP 2는 성공적이었으며 2022년 5월 모든 웹사이트의 46.4%가 사용하고 있다. 

이는 HTTP 2가 웹사이트, 어플리케이션을 바꾸지 않고도 사용할 수 있기 때문에 가능하다. (최신 브라우저와 통신하는 최신서버만 준비되면 된다)

HTTP 3 (HTTP over QUIC)

2.0에서는 하나의 연결안에서 여러개의 스트림이 전송된다. 여기서 하나의 패킷이 빠지거나 손실되면, 문제가 발생한 패킷을 다시 전송하고 목적지에 도달하는 동안 전체 TCP 연결이 중단된다.

이를 해결하기 위해서 UDP를 활용하여 TCP의 신뢰성을 보장하는 장점을 살리는 방안을 고민하다 QUIC가 등장한다.

QUIC는 Quick UDP Internet Connection의 약자로 구글이 UDP로 구현한 실험적인 다중 전송 프로토콜이다.

[QUIC의 주요 기능]
- 연결 설정 시간 단축
- 향상된 혼잡 제어
- HOL(Head of Line) 차단이 없는 멀티플렉싱
- 에러 연결 포워드
- 연결 마이그레이션

0-RTT, 1-RTT handshake를 활용하면 지연시간을 효율적으로 줄일 수 있다.

각 스트림을 스트림 식별자로 구분하여 독립적인 스트림을 갖는다. 스트림 중 어떤 패킷이 손실되면 해당 스트림만 중단된다. QUIC는 0-RTT, 1-RTT handshake를 모두 제공하기 때문에 기존의 3-way handshake로 발생되는 시간을 줄일 수 있다.

---

출처

https://velog.io/@emplam27/CS-%EA%B7%B8%EB%A6%BC%EC%9C%BC%EB%A1%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EB%8A%94-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%86%8C%EC%BC%93-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%EA%B3%BC-Handshaking

https://www.ibm.com/docs/en/zos/2.4.0?topic=services-what-is-socket 

https://pediaa.com/difference-between-socket-and-port/

https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP

https://techcommunity.microsoft.com/t5/itops-talk-blog/smb-over-quic-files-without-the-vpn/ba-p/1183449