HTTP 커넥션 관리(HTTP Parallel connection/Persistent Connection/Pipelined Connection)

우리는 이전에 HTTP의 기초(HTTP/MIME/URL/URI/버전별특성)와 TCP의 커넥션 관리(TCP piggyback, slow start, no_delay, time_wait)에 대해서 알아보았다.(아래 링크 참고)
 
https://kuveminton.tistory.com/48

HTTP 웹의 기초 / MIME / URL / URI / HTTP 1.0 / HTTP 1.1 / HTTP 2.0

 
https://kuveminton.tistory.com/49

HTTP 특징 알아보기 / HTTP TCP 커넥션 관리 / HTTP TCP 성능 지연 및 최적화

 
이번 포스팅에서는 HTTP 커넥션 관리에 대한 부분을 포스팅한다. 
 
HTTP Parallel Connection(병렬 커넥션)
HTTP Persistent Connection(지속 커넥션)
HTTP Pipelined Connection(파이프라인 커넥션) 
 
 
HTTP Parallel Connection(병렬 커넥션)
웹 포탈 서버에 접속했다고 가정하자. 
해당 포탈의 메인에는 많은 그림들과 텍스트 등이 존재한다. 
이런 자원들을 순차적인 커넥션을 이용하여 가져온다면 메인 화면의 로딩이 완료되는 시간까지 많은 시간이 걸릴것이다.
 
따라서 이러한 상황을 개선하기 위해 HTTP 클라이언트는 여러 개의 커넥션을 생성하여 병렬로 처리를 하는데 이 방식을 HTTP Parallel Connection 이라고 한다. 
 
하지만 Parallel connection이 장점만 있는 것은 아니다. 
다수의 커넥션을 동시에 사용하는 것은 메모리를 많이 소모하므로 서버의 성능을 많이 소모시키고 서버가 다수의 커넥션을 모두 허용할 수 없는 경우 해당 커넥션들을 임의로 terminate 할 수 있다. 
 
 
HTTP Persistent Connection(지속 커넥션)
HTTP/1.0+ 이후의 버전에서는 데이터 전송 처리가 완료된 후에도 TCP 커넥션을 유지하여 다음 HTTP 요청에 재사용할 수 있다. 이를 HTTP Persistent connection 이라고 한다. 
이러한 특성은 각 트랜잭션마다 새로운 커넥션을 맺고 끊을 필요가 없으므로 해당 시간과 대역폭의 소요를 막을 수 있다.
하지만 persistent connection 에 오류가 있을 경우 수많은 커넥션이 연결된 상태로 유지가 되어 리소스의 소모가 커질 수 있다. 
 
HTTP/1.0+ 이상에서는 Connection:Keep-Alive를 이용하여 persistent connection을 구현한다.
HTTP/1.1 이상에서는 Connection:Keep-Alive를 사용하지 않지만 persistent connection이 기본으로 활성화되어 있다.
Connection:Keep-Aliver는 HTTP/1.1의 명세에서 제외되었지만 아직도 많은 애플리케이션에서 Keep-Alive를 사용한다. 
 

 
 
HTTP/1.0 클라이언트 요청에 Connection:Keep-Alive 헤더가 없으면 서버는 해당 요청을 처리한 후 커넥션을 끊는다.
요청 헤더에 Connection:Keep-Alive 헤더가 존재하면 서버는 keep-alive 옵션에 맞게 커넥션을 유지한다. 
 
예) 아래는 서버가 5개의 추가 트랜잭션이 처리될 동안 커넥션을 유지하거나, 2분 동안 커넥션을 유지하라는 내용.
Connection: Keep-Alive 
Keep-Alive: max=5, timeout=120
 
HTTP/1.1 에서는 persistence connection이 기본으로 활성화되어 있으므로 트랜잭션이 끝난 커넥션을 끊으려면 Connection: Close 헤더를 명시해야 한다. 
 
 
HTTP Pipeline Connection(파이프라인 커넥션)
HTTP/1.1 에서 지원하는 Pipeline connection은 한개의 TCP connection 이 끝나기 전에 여러개의 HTTP 요청을 전송할 수 있다. Persistent connection은 트랜잭션의 요청/응답 이후 다음 트랜잭션의 요청/응답이 이어지는 반면 Pipeline connection은 트랜잭션의 응답을 받기 전에 다음 트랜잭션이 이어진다.(요청/요청/요청/응답/응답/응답의 형태)