HTTP 커넥션
HTTP 완벽 가이드의 일부를 정리한 내용이다.
1. 순차 커넥션, 병렬 커넥션, 지속 커넥션
순차 커넥션
가장 기본적인 방법이다. 한 커넥션당 하나의 요청을 처리하는 방법이다. 각 요청당 TCP를 구성하고 종료하는데 시간이 필요하다. 이는 순차적인 처리로 인하여 생기는 지연이다. 이 말고도 각 요청마다 TCP 커넥션을 새로 맺음으로써 TCP slow start 기능에 의한 지연이 발생할 수 도 있다.
병렬(Parallel) 커넥션
병렬 커넥션은 순차커넥션의 TCP를 구성하여 생기는 지연을 개선하고자 생긴 개념이다. 여러 커넥션을 만들어서 각각 요청을 전송하는 방법이다. 이렇게되면 TCP 구성 지연이 중첩되서 진행되므로 TCP구성 지연을 줄일 수 있는 장점이 있다. 하지만 이는 커넥션을 여러개 맺는다는 점에서 대역폭 분할, 서버 트래픽 증가로 이어질 수 있고 상황에 따라 오히려 처리 시간이 더 길어질 수 있다는 단점이 있다.
지속(Persistent) 커넥션
이전에 사용했던 커넥션을 종료하지 않고 재사용하는 방법이다. TCP 커넥션을 재사용함으로써 얻을 수 있는 장점은 TCP를 구성하는데에 사용하던 시간을 소요하지 않는다. 즉 TCP 구성 지연을 제거할 수 있다. 또한 하나의 커넥션으로 여러번 Server와 통신함으로써 TCP 커넥션은 slow-start 알고리즘에 의해 튜닝되어진다. 막 연결한 커넥션보다 많은 데이터를 한번에 보낼 수 있다는 의미이므로 더욱 빠르게 요청 및 응답을 할 수 있다는 의미이다. (데이터가 큰 Http 응답은 작은 IP 패킷 여러개로 이루어진다. 막 연결한 커넥션보다 튜닝된 커넥션은 한번에 더 많은 IP패킷을 전송할 수 있다.)
파이프 라인(pipelined) 커넥션
병렬 커넥션과 비슷해 보이지만 하나의 커넥션을 사용한다는 점에서 차이가 있다. 그리고 지속 커넥션과의 차이는 응답을 기다리지않고 요청을 보낸다는 것에 차이가 있다. 이 방식은 논 블록킹-비동기 처리방식이라고 생각한다. 커넥션을 한개만 맺어서 기존의 병렬 커넥션의 단점도 제거할 수 있는 방법이다 하지만 이 방법에도 주의해야할 점이 있다.
1. 커넥션이 기본적으로 지속 커넥션이어야 한다. - 여러 요청을 한번에 보냈지만 첫번째응답을 받고 종료해버리면 의미가 없기 때문이다.
2. HTTP응답은 순번이 없다. - 요청 순서와 동일하게 응답이 와야 한다. 동일하게 오지않으면 이를 재정렬할 방법이없다.
3. POST 요청과 같은 멱등성을 헤치는 요청은 파이프라인 커넥션을 사용하면 안된다. - 파이프 라인 커넥션을 수행중에 커넥션이 끊긴다면 어느 요청부터 끈켰는지 알 수가 없다. 고로 POST요청이 처리되고 나머지 요청을 처리 도중에 연결이 끊기면 파이프라인 모든 요청이 다시 시작되어야한다. 그러면 POST요청이 여러번 서버에 도달하게 되고 잘못된 데이터가 서버에 생기는 문제가 발생할 수 있다.
2. Connection 헤더
Connection헤더는 hop-by-hop 헤더를 기술한다. 두 개의 인접한 HTTP 애플리케이션이 현재 맺고 있는 커넥션에만 적용될 옵션을 지정할 때 사용한다.
HTTP1.1에서는 keep-alive를 사용하지 않기로 결정 하였지만 HTTP 1.0+ 버전까지는 Connection : keep-alive를 이용하여 지속 커넥션을 맺는데에 사용했다. 고로 아직도 브라우저와 서버 간에 keep-alive 핸드셰이크가 널리 사용되고 있다.
3. Keep-Alive 동작
Connection: keep-alive 헤더를 사용해서 지속 커넥션을 사용하는 방법이다. 동작 과정은은 요청에 Connection: keep-alive헤더를 포함하고 서버응답 헤더에 Connection: keep-alive가 포함되면 해당 커넥션은 지속 커넥션으로 사용된다. 서버 응답에 Connection: keep-alive가 없다면 클라이언트는 지속 커넥션을 사용하지 않는다고 알 수 있다.
이러한 동작 과정은 클라이언트와 서버 사이의 프록시가 존재하면 문제가 생길 수 있다. 자세히 알고싶으면 멍청한 프록시 Proxy-Connection등의 키워드로 검색해보자.
이러한 문제때문에 HTTP/1.1에서는 keep-alive 대신 더 개선된 방법으로 지속 커넥션을 지원한다. HTTP/1.1 커넥션은 모두 지속 커넥션으로 취급되며 커넥션을 끊을때는 Connection: close를 이용하여 연결을 끊는다. HTTP/1.1 클라이언트는 응답에 Connection: close가 없다면 커넥션을 계속 유지하자는 것으로 추정한다. 하지만 커넥션은 언제든 끊어질 수 있다.
'통신' 카테고리의 다른 글
RPC vs REST vs GraphQL (0) | 2021.09.23 |
---|---|
구글 크롬의 HTTP통신 지속 커넥트, 병렬 커넥트 (0) | 2021.09.05 |
TCP 성능 관련 중요 요소 (0) | 2021.01.29 |
HTTP 1.1 (0) | 2020.11.14 |
HTTP 1.0 (0) | 2020.11.11 |