웹 브라우저 요청 흐름 질문

안녕하세요, lch9502 님. 공식 서포터즈 codesweaver 입니다.
.
OSI 7 계층을 검색해보시면 TCP가 속해있는 Transport Layer위에 HTTP가 포함된 Application Layer가 있는 것을 볼 수 있습니다. 즉, HTTP는 이 TCP(혹은 UDP)를 이용한 응용 기술이라는 뜻입니다. 결론적으로 모든 HTTP 요청은 TCP 혹은 UDP로 구현될 수 밖에 없습니다.
.

그 외에 도움이 되실만한 내용을 설명 드립니다.

.

우리가 어떤 URL을 입력하게 되면(www.example.com을 입력하면) 우선 DNS에서 이 URL에 해당하는 IP 주소를 획득해야 합니다. 이때 사용자가 위치에서 가장 가까운 DNS(로컬 DNS)에 IP주소를 질의(query)하게 됩니다. 로컬 DNS내부에 해당 URL가 매칭되는 IP주소가 캐싱되어 있지 않다면 로컬 DNS는 루트 DNS로 www.example.com IP주소를 질의합니다. 루트 DNS 에서도 www.example.com을 알지 못하기에 .com 을 관리하는 DNS의 주소를 알려줍니다. 그러면 로컬 DNS는 .com 을 관리하는 DNS 서버로 가서 www.example.com 을 질의 합니다. 이런식으로 최종 IP 주소를 알아낼 때까지 질의를 반복합니다. (이를 DNS iterative query 라고 합니다)

.

이제 아이피 주소를 발견하게 되면 SYN 신호를 해당 아이피로 보냅니다. 이를 받은 서버는 SYN+ACK 신호를 보내게 되고, 클라이언트가 최종 ACK 신호를 보내며 3-way handshake를 하게 됩니다. 웹 초창기에는 모든 데이터에 이 3-way handshake를 해야 했기에 효율이 매우 나빴습니다. 그래서 HTTP/1.1 부터는 'HTTP 지속 연결 상태'(persistence connection) 이라는 개념을 도입, 모든 바이트에 3-way handshake를 하는 것이 아니라 최초에 핸드쉐이크를 하고 이후에는 계속 연결을 유지하는 방식을 도입하였습니다. 모든 연결이 끝났을때 헤더에 연결 종료를 알림으로써 TCP 연결을 끊는 식입니다.

.

이 HTTP 지속 연결 상태를 기반으로 HTTP 파이프라이닝 이라는 기술도 같이 적용되었습니다. 이는 한번 연결된 TCP 연결을 기반으로 여러개의 요청을 '병렬' 요청함으로써 FIFO 방식 처리의 단점인 지연(latency) 문제를 해결하였습니다.

.

이후 HTTP/2.0 에서는 최초 TCP 연결 이후 스트림(stream) 방식으로 여러 요청을 처리하는 멀티플렉싱 기능을 도입하여 더욱 속도 향상을 이루었고, HTTP/3.0에서는 아예 TCP가 아닌 UDP 방식으로 데이터를 전송함으로써 3-way handshake를 아예 하지 않아도 되는 식으로 발전하고 있습니다.

감사합니다.

답변 정말 감사합니다!

그러면 3-way-handshake는 HTTP로 요청/응답을 하기 전에 설정한다는 것이라서 HTTP와는 상관이 없다는 것이고,

만약 3-way-handshake 이후에 요청/응답을 TCP로 하면 계속 연결이 되어있는 상태며, 요청/응답을 HTTP로 하면 한번 통신 후에 끊긴다는 것으로 이해하면 될까요??