HTTP 커넥션

2021. 2. 1. 15:58

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

BELATED ARTICLES

more