HTTP Connection 헤더

Connection 헤더에 포함되는 3가지 토큰

• HTTP 헤더 필드 명 : 이 커넥션에만 해당되는 헤더 나열
  • 다른 커넥션에 전달하면 안된다!
  • 메시지를 다른 곳으로 전달하는 시점에 삭제되어야한다.
  • hop-by-hop 헤더 명을 기술한다. (두 서버에만 영향을 미치는)
• 임시적인 토큰 값 : 커넥션에 대한 비표준 옵션
• close 값 : 작업이 완료되면 커넥션이 종료되어야함

Connection 헤더와 함께 메시지를 전달받으면, 요청에 기술되어 있는 모든 옵션을 적용한다.
그리고 다음 서버에 메시지를 전달하기위해 Connection 헤더, Connection 헤더에 기술되어 있던 모든 헤더를 삭제한다. (hop-by-hop 헤더 삭제)

커넥션 관리로 인한 지연

커넥션 관리가 제대로 이뤄지지 않으면 TCP 성능이 저하될 수 있다. 예를 들어 순차적으로 트랜잭션을 처리하여 각 트랜잭션마다 커넥션을 맺는다면 커넥션 맺는 시간 + slow start 지연이 발생할 수 있다.
이러한 지연을 방지하기 위한 네가지 기술이 있다.

• 병렬 커넥션
• 지속 커넥션
• 파이프라인 커넥션
• 다중 커넥션

병렬 커넥션

병렬 커넥션은 커넥션의 지연 시간을 겹치게 하여 총 지연 시간을 줄일 수 있는 커넥션 방식이다.
일반적으로 더 빠르긴 하지만 항상 더 빠른 것은 아니다. (ex. 네트워크 대역폭이 좁을 때)
또한 다수의 커넥션을 맺어 메모리를 많이 소모하고 자체적인 성능 문제를 발생시킨다.

단점

• 각 트랜잭션마다 새로운 커넥션을 맺어 시간과 대역폭이 소모된다.
• slow start로 인한 지연으로 성능이 떨어진다.
• 실제로 연결할 수 있는 병렬 커넥션의 수에 제한이 있다.

지속 커넥션

처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로의 HTTP 요청이 들어올 때 재사용하는 커넥션 방식이다. 비 지속커넥션의 경우 각 처리가 끝날 때마다 커넥션을 끊지만, 지속 커넥션은 클라이언트 or 서버가 커넥션을 끊기 전까지 커넥션을 유지한다.

장점

• 이미 맺어진 커넥션을 재사용하므로, slow start로 인한 지연을 피할 수 있다.
• 커넥션을 맺기위한 준비 시간을 줄일 수 있다.

단점

• 잘못 관리할 경우, 연결상태로 지속되는 커넥션이 쌓이게 됨 -> 리소스 낭비!

단점의 보완

지속 + 병렬 커넥션의 방식

• HTTP/1.0 --> keep-alive

  Connection 헤더에 keep-alive를 포함시킨다. 이러한 요청을 받은 서버는 다음 요청도 똑같은 커넥션에 받고자 한다면 응답에 keep-alive를 포함시키면 된다. 응답에 해당 헤더가 없으면 클라이언트는 keep-alive를 지원하지 않으며, 응답이 전송된 이후 서버가 커넥션을 끊을 것으로 추정한다.
  Content_Length 값과 멀티파트 미디어 형식을 가지거나 or 청크 전송 인코딩으로 인코딩 되어서 트랜잭션이 끝나는 시점에 기존 메시지의 끝을 알 수 있도록 해야한다!

• HTTP/1.1 --> 지속 커넥션

  HTTP/1.1에서는 keep-alive를 지원하지 않는 대신, 개선된 지속 커넥션을 지원한다. HTTP/1.0의 keep-alive와 달리 별도 설정을 하지 않는 한, 모든 커넥션을 지속 커넥션으로 취급한다.
  트랜잭션을 끊기 위해서는 Connection:close를 포함해야한다.
  얘도 동일하게 Content_Length 값 or 청크 전송 인코딩으로 인코딩 되어야한다.
  HTTP/1.1 프락시는 클라이언트, 서버에 대해 별도의 지속 커넥션을 맺고 관리해야한다.
  중간에 끊어지는 커넥션을 복구할 수 있어야만 한다.

파이프라인 커넥션

HTTP/1.1은 지속 커넥션을 통해서 요청을 파이프 라이닝 할 수 있다. (실행중인 명령이 끝나기 전에 다른 명령의 실행을 시작한다.)

제약 사항

• HTTP 클라이언트는 커넥션이 지속 커넥션인지 확인 하기 전에 파이프라인을 이어서는 안된다.
• HTTP 응답은 요청 순서와 같게 와야한다. (HTTP 메시지에 순번이 매겨져있지 않음)
• 클라이언트는 커넥션이 언제 끊기더라도, 완료되지 않ㅇ는 요청이 파이프라인에 있으면 언제든 다시 요청을 보낼 준비가 되어있어야한다.
• POST 요청같이 반복해서 보낼 경우 문제가 생기는 요청은 파이프라인으로 보내면 안된다.
  • 멱등 요청 : GET, HEAD, PUT, DELETE, TRACE, OPTIONS
• 각 응답은 정확한 Content-Length 헤더를 가지고 있어야한다.

커넥션 끊기

커넥션은 에러가 없더라도 언제든지 끊을 수 있다. 또한, 예상치 못하게 커넥션이 끊겨도 적절한 대응을 할 수 있어야한다.

트랜잭션 수행 중에 커넥션이 끊기면, 해당 트랜잭션을 재시도해도 문제가 없다면 커넥션을 다시 맺고, 한 번 더 전송한다.
=> 문제가 생기는 경우는 POST(비 멱등)로 전송했을 경우. 비멱등 요청을 다시 보내야하면, 이전 요청에 대한 응답을 받을 때까지 기다린다.

전체 끊기, 절반 끊기

TCP 커넥션은 입력 큐, 출력 큐 양방향으로 이뤄져있다.

• 전체 끊기 : close()를 호출하면 입, 출력 채널의 커넥션이 모두 끊어진다.
• 절반 끊기 : shutdown()을 호출한다.

단순 HTTP는 전체 끊기만을 사용할 수 있지만, 각 클라이언트, 서버, 프락시와 통신할 때, 그들과 파이프라인 지속 커넥션을 사용할 때는 예상치못한 쓰기 에러를 예방하기 위해 절반 끊기를 사용해야한다.

클라이언트에서 입력 채녈을 끊는 것은 위험하다.
그래서, 자신의 출력 채널을 먼저 끊고, 다른 쪽에 있는 출력 채널이 끊기는 것을 기다린다.

---

이 글은 HTTP 완벽 가이드를 읽고 정리한 글입니다.
저작권 및 기타 문제가 있으면 댓글로 알려주세요.
감사합니다.