Connection 관리

HTTP통신은 TCP/IP내에서 이루어진다.

Tcp는 신뢰할 수 있는 통신 방식을 제공한다. 각 데이터들이 세그먼트로 나뉘어 IP패킷을 통해 전송된다

|   API    |설명|
|:--------:|:---:|
| socket() |소켓 생성|
| bind()   |소켓에 주소 할당|
| listen() |연결 요청 대기|
| accept() |연결 요청 수락|
| connect()|연결 요청|
| send()   |데이터 송신|
| recv()   |데이터 수신|
...

소켓 API는 TCP endpoint 데이터 구조를 생성하고 원격서버에 연결하여 데이터 스트림을 읽고 쓸 수 있다. 기본적인 테트워크 핸드쉐이킹과 TCP 데이터 스트림 IP 패킷 간 분할&재조립에 대한 모든 세부사항을 외부로 부터 숨긴다.

HTTP 네트워크 지연

TCP 커넥션을 설정하고 요청하고 응답을 보내는것 보다 트랜잭션을 처리하는 시간은 상당히 짧다. 그럼에도 지연이 발생하는데 아래와 같은 이유가 원인이다.

DNS 이름 분석을 하는 시간이 걸린다. 서버의 커넥션 허가 응답을 기다린다. 서버가 데이터를 처리하는 시간에 의해 지연된다.

확인 응답의 크기는 작기 때문에 같은 방향으로 송출되는 확인 응답을 편승 시킨다. 많은 TCP 스택은 송출데이터+확인응답을 하나로 묶어 확인 응답 지연 알고리즘을 구현한다.

TCP의 데이터 전송 속도는 TCP 커넥션이 만들어 진 시간에 따라 달라진다. Slow start라 부르며 처음엔 느렷다 점차 전송할 수 있는 패킷의 수를 증가시킨다

Nagle : 아주 작은 데이터도 전송 할 수 있도록 데이터 스트림 인터페이스를 제공한다. 각 세그먼트는 40byte 크기의 플래그와 헤더를 함께 보내기때문에 아주 작은 크기의 데이터를 전송한다면 성능은 크게 떨어지게 된다. 이러한 이유로, Nagle은 1500바이트 정도 데이터가 되지 않으면 전송을 하지 않는다 크기가 아주 작은 Http 메시지는 패킷을 채우지 못하기 때문에 전송을 하지 못할 수 있으며, 확인 응답 지연과 함께 쓰이는 경우 응답을 지연시킨다.

TIME WAIT

성능 측정 시 심각한 저하를 발생시키는데, 보통 실제 상황에서는 문제가 잘 생기지 않는다. TCP 종단에서 커넥션이 끊기면 IP주소와 포트번호를 메모리의 작은 영역에 기록한다. 세그먼트의 생명주기의 두배정도 유지되며, 같은 주소와 포트를 사용하는 연결을 다시 생성하지 않게 하기 위함이다.

이전의 커넥션 패킷과 중복되는 패킷이 생긴다면, TCP 데이터가 충돌하며 패킷이 중복된다 일반적으로 커넥션 종료 지연이 문제가 되진않지만, 성능 테스트시엔 IP와 서버의 수가 제한되어 있기에 자주 발생할 수 있게된다. 발신지 포트의 수는 제한되어 있으며 ( 6만개) 2MSL(120초) 동안 재사용 될수 없기에 초당 500개 까지 연결이 제한될 수 있다.

HTTP Connection

Http는 중개 서버가 놓이는 경우가 종종 있는데, Client부터 서버까지에 이르는 사이 사이에 존재한다. Http 어플리케이션이 현재 맺고 있는 커넥션에만 적용될 옵션을 지정해야 하는 경우가 있는데. 커넥션 토큰을 쉼표로 구분하여 가지고 있어, 다른 커넥션엔 전달되선 안된다.

홉별 헤더명을 기술하는데, Connection헤더에 명시된 헤더들이 전달되는 것을 방지하기 때문이다.

성능 개선

※브라우저는 대부분 4개의 병렬 커넥션만 허용한다.

웹 클라이언트는 보통 같은 사이트에 커넥션을 맺는데, 이 커넥션을 유지하는것을 지속 커넥션이라고 한다. 커넥션을 맺고 끊는 작업을 하지않아 시간이 단축된다

홉별 헤더들은 다음 홉에 헤더를 전달하면 안된다.

http1.0엔 keep alive 옵션으로 커넥션 유지 요청을 했지만. 1.1 버전 이후부터 명세에서 제거되었다