본문 바로가기

HTTP 정리

1부 4장 - 커넥션 관리 - 1

4.1 TCP 커넥션


전 세계 모든 HTTP 통신은, 패킷 교환 네트워크 프로토콜의 계층화된 집합인 TCP / IP를 통해 이루어진다.

일단 커넥션이 맺어지면 메시지들은 손실 혹은 손상되거나 순서가 바뀌지 않고 안전하게 전달됨.



4.1.1 신뢰할 수 있는 데이터 전송 통로, TCP


HTTP 커넥션은 몇몇 규칙을 제외하고는 TCP 커넥션에 불과하다.

TCP 커넥션의 한 쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확히 전달됨.


4.1.2 TCP 스트림은 세그먼트로 나뉘어 IP 패킷을 통해 전송됨


TCP는 IP 패킷 (혹은 IP 데이터 그램) 이라고 불리는 작은 조각을 통해 데이터를 전송함


TCP 세그먼트 구성 요소

-    IP 패킷 헤더

-    TCP 세그먼트 헤더

-    TCP 데이터 조각

(p88 그림 참조)


4.1.3 TCP 커넥션 유지하기


TCP는 포트번호를 통해서 여러개의 커넥션을 유지한다.

IP 주소는 해당 컴퓨터에 연결되고 포트 번호는 해당 애플리케이션으로 연결된다.


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


위 네가지 값으로 유일한 커넥션을 생성한다.

서로 다른 두 개의 TCP 커넥션은 네 가지 값이 모두 같을 수 없다.


4.1.4 TCP 소켓 프로그래밍


운영 체제는 TCP 커넥션의 생성과 관련된 여러 기능 제공.

소켓 API는 HTTP 프로그래머에게 TCP와 IP의 세부사항들을 숨김.

소켓 API를 사용하면, TCP 종단(endpoint) 데이터 구조를 생성하고, 원격 서버의 TCP 종단에 그 종단 데이터 구조를 연결하여 데이터 스트림을 읽고 쓸 수 있다.



4.2 TCP의 성능에 대한 고려


HTTP 트랜잭션의 성능은 그 아래 계층인 TCP 성능에 영향을 받는다.



4.2.1 HTTP 트랜잭션 지연


대부분의 HTTP 지연은 TCP 네트워크 지연으로 발생.

TCP 네트워크 지연은 하드웨어 성능, 네트워크와 서버의 전송 속도, 요청과 응답 메시지의 크기, 클라이언트와 서버간의 거리, TCP 프로토콜의 기술적인 복잡성과 연관됨.


4.2.2 성능 관련 주요 요소


일반적인 TCP 관련 지연들

-    TCP 커넥션의 핸드세이크 설정

-    TCP의 느린 시작 (slow-start)

-    네이글(nagle) 알고리즘

-    확인 응답 지연 알고리즘

-    TIME-WAIT 지연과 포트 고갈


4.2.3 TCP 커넥션 핸드셰이크 지연


새로운 TCP 커넥션을 열 때면, TCP 소프트웨어는 커넥션을 맺기 위한 조건을 맞추기 위해 연속으로 IP 패킷을 교환한다.


- 핸드셰이크 순서


1. 클라이언트는 새로운 TCP 커넥션을 생성하기 위해 작은 TCP 패킷을 서버에게 보냄. 이 패킷은 'SYN' 이라는 플래그를 가지는데, 커넥션 생성 요청이라는 뜻.

2. 서버가 커넥션을 받으면 몇 가지 커넥션 매개변수를 산출하고, 요청이 받아들여졌음을 의미하는 'SYN'과 'ACK' 플래그를 포함한 TCP 패킷을 클라이언트에게 보낸다.

3. 마지막으로 클라이언트는 커넥션이 잘 맺어졌음을 알리기 위해서 서버에게 다시 확인 응답 신호를 보낸다. 이 때, 데이터도 같이 보낼 수 있다.


4.2.4 확인 응답 지연


인터넷 자체가 패킷 전송을 완벽히 보장하지는 않기에 TCP는 성공적인 데이터 전송을 위해 자체적인 확인 체계를 가짐.


각 TCP 세그먼트의 수신자는 세크먼트를 온전히 받으면 작은 확인 응답 패킷을 송신자에게 반환하고, 송신자가 특정 시간 안에 확인 응답 메시지를 받지 못하면 데이터를 다시 전송함.


확인 응답은 그 크기가 작기 때문에, 같은 방향의 데이터 송출 패킷에 확인 응답을 편승시킴. 같은 방향으로 가는 데이터 패킷에 편승되는 경우를 늘리기 위해서, 많은 TCP 스택이 확인 응답 알고리즘을 구현함.

막상 편승할 패킷을 찾으려고 하면 해당 방향으로 송출될 패킷이 많지 않기 때문에, 확인 응답 지연 알고리즘으로 인한 지연이 자주 발생함.


4.2.5 TCP 느린 시작 (slow start)


TCP 커넥션은 시간이 지나면서 자체적으로 '튜닝' 되어서, 처음에는 커넥션의 최대 속도를 제한하고 데이터가 성공적으로 전송됨에 따라서 속도 제한을 높여 나간다. (급작스러운 부하와 혼잡 방지)


TCP가 한번에 전송할 수 있는 패킷의 수를 제한한다. 패킷에 대해 확인 응답을 받을 때마다 전송 가능한 패킷이 증가한다.


이런 기능 때문에, 새로운 커넥션은 '튜닝'된 커넥션보다 느리다. 이미 존재하는 커넥션을 재사용하는 기능이 있다. (지속 커넥션)


4.2.6 네이글 알고리즘과 TCP_NO DELAY


- TCP 데이터 스트림 인터페이스


애플리케이션이 어떤 크기의 데이터든지 TCP 스택으로 전송할 수 있게 함.


하지만 TCP가 작은 크기의 데이터를 포함한 많은 수의 패킷을 전송한다면 네트워크 성능은 크게 떨어진다.


- 네이글 알고리즘


네트워크 효율을 위해서, 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한 개의 덩어리로 합침.


세그먼트가 최대 크기가 되지 않으면 전송을 하지 않음. 다만 다른 모든 패킷이 확인 응답을 받았을 경우에는 최대 크기보다 작은 패킷의 전송을 허락한다.


- 문제점


크기가 작은 HTTP 메시지는 패킷을 채우지 못해서, 앞으로 생길지 어떨지 모르는 추가적인 데이터를 기다리며 지연될 것이다.


확인 응답 지연과 함께 쓰일 경우 형편없이 동작함.


- TCP_NODELAY


성능 향상을 위해서 이 파라미터 값을 설정하여 네이글 알고리즘을 비활성화하는 기능


설정했다면, 작은 크기의 패킷이 너무 많이 생기지 않도록 큰 크기의 데이터 덩어리를 만들어야 함.



4.3 HTTP 커넥션 관리



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


HTTP/1.1 에서 Connection 헤더의 값은 헤더의 이름에 대응되는 토큰의 목록이다. 이 헤더가 포함된 메시지를 받는 애플리케이션은 그 목록을 파싱하고 얻은 헤더들을 메시지에서 지우도록 되어있다.


이 헤더는 주로 프락시를 위한 것으로, 홉과 홉 사이에서만 사용하므로 그 다음 홉으로 넘겨줘서는 안 될 헤더들을 서버나 다른 프락시가 지정할 수 있게 해줌.


4.3.2 순차적인 트랜잭션 처리에 의한 지연


커넥션 관리가 제대로 이루어지지 않으면 TCP 성능이 매우 안 좋아질 수 있다.


HTTP 커넥션 성능 향상을 위한 여러 기술들


- 병렬 커넥션: 여러개의 TCP 커넥션을 통한 동시 HTTP 요청

- 지속 커넥션: 커넥션을 맺고 끊는 데서 발생하는 지연을 제거하기 위한 TCP 커넥션 재활용

- 파이프라인 커넥션: 공유 TCP 커넥션을 통한 병렬 HTTP 요청

- 다중 커넥션: 요청과 응답들에 대한 중재

'HTTP 정리' 카테고리의 다른 글

1부 4장 - 커넥션 관리 - 2  (0) 2019.01.16
1부 3장 - HTTP 메시지  (0) 2019.01.01
1부 2장 - URL과 리소스  (0) 2018.12.25
1부 1장 - HTTP 개관  (0) 2018.12.16