[HTTP 이해하기] TCP / IP 프로토콜 및 TCP 커넥션 관련

1. TCP / IP 개요

오늘날 인터넷 환경은 TCP / IP 프로토콜 슈트(protocol suite)를 기반으로 구성되었습니다. 우리가 브라우저에서  https://bloodseeker.tistory.com/을 쳤을 때 TCP / IP 프로토콜 슈트에서 브라우저와 서버를 연결해주고 통신을 하도록 합니다.

TCP / IP 프로토콜 슈트라고 해서 TCP , IP 2개 프로토콜만 있는것이 아닙니다. 다른 많은 포로토콜들과 함께 구성되었는데 그냥 TCP, IP가 가장 핵심적인 프로토콜이고 널리 알려져있기 때문에 그렇게 부른다고 한다. 실제로 위키에서 TCP / IP 프로토콜을 검색하면 하기와 같이 Internet protocol suite으로 나옵니다. https://en.wikipedia.org/wiki/Internet_protocol_suite

The Internet protocol suite, commonly known as TCP/IP, is the set of communication protocols used in the Internet and similar computer networks. The current foundational protocols in the suite are the Transmission Control Protocol (TCP) and the Internet Protocol (IP), as well as the User Datagram Protocol (UDP).

2. TCP / IP 구조

출처:http://www.steves-internet-guide.com/internet-protocol-suite-explained/

그림과 같이 TCP / IP 는 4개 layer로 구성되어 있습니다. 발신지에서는 메시지가 Application Layer에서 출발해서 한층한층 내려가 Physical Layer에서 목적지에 전달됩니다. 반대로 목적지에서는 Pysical Layer에서 Application Layer로 한층한층 올라가서 목적지 서버에 도착하게 됩니다.

Application Layer

• 우리가 웹 서비스를 개발하면서 사용하는 프로토콜들은 모두 해당 layer에 있다고 생각하면 됩니다. 
• 해당 layer의 프로토콜을 사용함으로써 웹 개발자들은 클라이언트와 서버사이에서 커넥션은 어떻게 맺는지, 실제 data는 어떻게 교환되는지를 몰라도 서비스를 개발 할수 있습니다.
• HTTP, SMTP, FTP, POP3 등

Transport Layer

• 해당 layer에서 TCP 프로토콜을 사용합니다.
• TCP 프로토콜은 클라이언트와 서버사이 신뢰성있는 커넥션을 맺고 관리합니다. 커넥션이 맺어지면 클라이언트와 서버 간에 주고받는 메시지들은 손실 혹은 손상되거나 순서가 바뀌지 않고 항상 안전하게 전달됩니다.
• TCP 커넥션에는 지속커넥션, 병렬커넥션, 파이프라인 커넥션 등이 있습니다.
• TCP에선 application layer에서 받은 메시지들을 세그먼트(Segment)로 나뉩니다.
  https://en.wikipedia.org/wiki/Transmission_Control_Protocol#:~:text=A%20TCP%20segment%20consists%20of,data%20carried%20for%20the%20application.

Network Layer

• 해당 layer에서 IP 프로토콜을 사용합니다. IPv4, IPv6 등
• 해당 Layer에서는 IP와 port 번호로 인터넷 환경에서 두 device를 연결해주고 패킷(Packet)단위로 data를 전송하는 역할을 합니다.
• 패킷은 Transport Layer에서 전달해주는 Segment에 IP주소(발신지, 목적지)를 비롯한 여러가지 정보를 추가해서 만들어 집니다.

Pyhsical Layer

• 실제 data를 전송하는 물리적인 layer로 생각하면 될것 같습니다. Ethernet과 같은 프로토콜이 존재하는 layer입니다.
• Datalink Layer, Network Interface Layer등으로도 불리기도 합니다.

이외에 HTTPS를 사용하면 Application Layer와 Transport Layer 사이 SSL 혹은 TLS 라는 보안 Layer가 존재한다.

SSL 혹은 TLS

• 보안 Layer 입니다. 
• HTTPS에서는 모든 메시지가 암호화 되어서 전달됩니다. 해당 layer에서는 클라이언트와 서버 사이에서 암호화 / 복호화에서 사용하는 key(session key)를 생성하는 역할을 합니다. 향후에 HTTPS를 설명하는 포스트에서 좀 더 구체적으로 설명하겠습니다.

3. TCP 커넥션

http://www.kyobobook.co.kr 이라는 사이트를 방문하면 하기와 같이 동작합니다.

(1). 브라우저가 www.kyobobook.co.kr이라는 호스트명을 추출한다
(2). 브라우저가 이 호스트 명에 대한 IP주소(211.189.37.30)를 찾는다.
(3). 브라우저가 포트번호(80)을 얻는다.(IP주소, 포트번호는 chrome 개발자도구 -> 네트워크 탭에서 확인할수 있음)
(4). 브라우저가 211.189.37.30의 80포트로 TCP 커넥션을 생성한다.
(5). 브라우저가 서버로 HTTP GET 요청 메시지를 보낸다.
(6). 브라우저가 서버에서 온 HTTP 응답 메시지를 읽는다.
(7). 브라우저가 커넥션을 끊는다(지속 커넥션이면 끊지 않고 유지할것임).

TCP는 하기와 같은 네가지 값으로 유일한 커넥션을 생성합니다. 때문에 컴퓨터는 동시에 여러개 TCP 커넥션을 가질 수 있습니다.

<발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트>

3.1 TCP 커넥션 지연

트랜잭션:  웹 개발에서 많이 사용하는 단어입니다. 한개의 트랜잭션은 클라이언트의 요청과 그에 대한 응답으로 구성되어 있습니다.

한번의 트랜잭션에 소요되는 시간은 다음과 같습니다.

• 클라이언트는 DNS 로 URL에 있는 호스트 명을 IP 주소로 변환해야 합니다(DNS 분석은 이제 밀리초 단위로 됨. 추가로 DNS 캐시도 있어서 순간적으로 처리될수도 있음).
• TCP 커넥션의 연결(TCP 커넥션의 핸드셰이크)에 시간이 소요됩니다. 보통 1초 미만으로 소요되지만 수백 개의 HTTP 트랜잭션이 만들어지면 소요시간도 크게 증가됩니다.
• HTTP 요청을 보내는데 시간이 소요됩니다.
• HTTP 응답을 보내는데 시간이 소요됩니다.

추가적으로 하기와 같은 TCP 관련 네트워크 지연이 존재합니다.

• TCP 커넥션의 핸드셰이크 설정: 어떤 데이터를 전송하든 새로운 TCP 커넥션을 열 때면 클라이언트와 서버사이에서 연속으로 IP 패킷교환을 합니다.
• 인터넷의 혼잡을 제어하기 위한 TCP의 slow-start: TCP 데이터 전송 속도는 컨넥션이 만들어진 초반에는 속도가 제한되고 데이터가 성공적으로 전송됨에 따라 속도 제한을 높여나간다(시간에 따라 튜닝된다고 표현한다). 
• 데이터를 한데 모아 한 번에 전송하기 위한 nagle 알고리즘: IP패킷을 전송하기 전에 많은 양의 TCP 데이터를 한개 덩어리로 합친다. 세그먼트가 최대 크기가 되지 않으면 전송을 하지 않고 기다린다.

현대 한장의 웹페이지에 수십번의 트랜잭션이 일어나기때문에 매 트랜잭션마다 위와 같은 지연들이 발생하면 웹페이지를 방문하는데 너무 많은 시간이 소요하게 됩니다. 때문에 이러한 지연을 없애기 위해서 병렬 커넥션, 지속 커넥션 등 기술들이 개발 되었습니다.

3.2 흔히 잘못 이해하는 Connection 헤더

HTTP는 클리아언트와 서버 사이에 proxy 서버, cache 서버 등과 같은 중개 서버가 놓이는 것을 허락합니다. HTTP 메시지는 클라이언트에서 서버까지 중개 서버들을 하나하나 거치면서 전달됩니다.

두 개의 인접한 HTTP 애플리케이션(예를 들어 클라이언트와 첫번째 proxy 서버사이, 마지막 proxy 서버와 서버 사이)사이에만 적용될 옵션을 지정해야 할 때 Connection 헤더를 사용합니다.

• 쉼표로 구분하여 가지고 있음.
• Connection 헤더에 있는 모든 헤더 필드는 메시지를 다른 곳으로 전달하는 시점에 삭제되어야 함.

Connection 헤더에는 다음 세 가지 종류의 토큰이 포함될 수 있다.

• HTTP 헤더 필드 명: 해당 헤더들은 이번 커넥션에만 존재함.
• 임시적인 토큰값: 커넥션에 대한 비표준 옵션.
• close: 커넥션이 작업이 완료되면 종료되어야 함을 의미.

클라이언트 -> proxy 서버 -> 서버 구조일 때

서버에서 proxy서버에 하기와 같은 HTTP 메시지가 전달되면

HTTP/1.1 200 OK
Cache-control: max-age=3600
Connection: disappear, close, test
Disappear: max-uses=3, max-refuses=6, dont-report

- Disappear 헤더는 proxy 서버에서 클라이언트로 전달되지 않음.
- close 옵션으로 proxy 서버와 서버사이 커넥션이 본 메시지 전달 후 끊어짐.
- test라는 비표준 옵션을 proxy 서버에 전달 함.

4. 병렬(Paraller) 커넥션

동시에 여러개 트랜잭션을 보냅니다. 때문에 한개 웹페이지를 내려받는 시간이 줄어듭니다. 현재 최신 브라우저들은 대부분 6~8개 병렬 커넥션을 지원합니다. 병렬 커넥션은 다음과 같은 단점들이 있습니다.

• 서버의 부하가 커지면서 성능이 떨어지게 됨(100명의 사용자가 각각 100개의 커넥션을 맺으면 총 10000개 커넥션을 떠안게 됨). 
• 각 트랜잭션마다 새로운 커넥션을 맺고 끊기 때문에 시간과 대역폭이 소요됨.
• 각각의 새로운 커넥션은 TCP slow-start 때문에 성능이 떨어짐.
• 실제로 연결할 수 있는 병렬 커넥션의 수에는 제한이 있음.

5. 지속(Persistent) 커넥션

출처:https://en.wikipedia.org/wiki/HTTP_persistent_connection

위의 그림과 같이 지속 커넥션은 한번의 트랜잭션이 끝난 후 커넥션을 끊지 않고 그 다음 트랜잭션도 해당 커넥션을 계속 사용하도록 하는 기술입니다. 

HTTP / 1.0 에서는 keep-alive 헤더를 명새해야 사용할 수 있고 HTTP / 1.1은 default로 지속 커넥션을 지원합니다.

5.1. HTTP / 1.0 keep-alive

HTTP / 1.0 에서 keep-alive 헤더는 다음과 같이 사용합니다. 주의할 점은 서버는 자신의 상황에 따라 keep-alive 헤더가 포함된 요청이 와도 커넥션을 유지하지 않아도 됩니다.

• max: Keep-Alive 응답헤더를 통해 보낸다. 최대 몇 개의 HTTP 트랜잭션을 처리할 때까지 유지될것인지를 의미한다.
• timeout: Keep-Alive 응답헤더를 통해 보낸다. 커넥션이 얼마간 유지될 것인지를 의미한다.

HTTP/1.0 에서는 하기 헤더를 추가해야 커넥션이 유지된다.
하기 요청은 최대 5개 트랜잭션을 처리할 동안 유지되고 최대 120초 동안 유지됨.

Connection: Keep-Alive
Keep-Alive: max=5, timeout=120

5.2 Keep-Alive 와 dump proxy

고전 버전의 proxy들은 Connection 헤더를 인식하지 못하기 때문에 keep-alive 와 dump proxy 이슈가 있습니다.

• 클라이언트는 프락시에 Connection: Keep-Alive 헤더와 함께 메시지를 보냄.
• 멍청한 프락시는 해당 메시지를 그대로(Connection 헤더 포함) 서버에 전달함.
• 웹 서버는 Connection: Keep-Alive 헤더를 보고 프락시가 커넥션을 유지하자고 요청한다고 판단함.
• 멍청한 프락시는 웹 서버에서 보내온 Connection: Keep-Alive 가 포함된 응답 메시지를 그대로 클라이언트한테 보냄.
• 클라이언트는 응답 메시지를 받고 keep-alive 커넥션이 연결된것으로 생각하고 해당 커넥션으로 그 다음 메시지를 보냄.
• 프락시는 서버가 커넥션을 끊기를 기다리고 있음으로 클라이언트에서 새롭게 보내는 메시지는 모두 무시함. 서버는 반대로 프락시와 계속 연결을 유지함(keep-alive).

5.3 Proxy-Connection

해결책으로 Proxy-Connection 비표준 확장 헤더를 추가하였습니다. Proxy Connection에 keep-alive 값을 추가함으로써 dump proxy는 해당 헤더를 그대로 서버에 전달하고 영리한(?) proxy는 해당 헤더를 Connection 헤더로 변경해서 서버에 보냅니다.

5.4 HTTP/1.1의 지속 커넥션

HTTP/1.1 에서는 keep-alive 커넥션을 지원하지 않고 설계가 더 개선된 지속 커넥션을 지원합니다. keep-alive와 같지만 그에 비해 더 잘 동작합니다. HTTP/1.1에서는 지속 커넥션이 기본으로 활성화되어 있습니다.

HTTP/1.1에서 클라이언트는 트랜잭션이 끝난 다음 커넥션을 끊으려면 Connection: close 헤더를 명시해야 합니다. 클라이언트가 해당 헤더를 보내지 않아도 서버는 자신의 상황에 맞춰서 커넥션을 끊을 수도 있습니다.

오늘날 브라우저들은 병렬 커넥션과 지속 커넥션을 결합하여 사용합니다.

참고:

https://www.techtarget.com/searchnetworking/definition/TCP-IP

TCP/IP: What is TCP/IP and How Does it Work?

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788966261208 

HTTP 완벽 가이드 - 교보문고