11. Connection close ← mystry

10. Connection: close ← mystry

Connection 끊기의 허용, 재사용, 멱등성

• 커넥션은 에러가 없더라도 언제든 끊을 수 있다.
• 클라이언트가 트랜잭션을 수행 중 전송 커넥션이 끊기게 되면, 클라이언트는 그 트랜잭션을 재시도 하더라도 문제가 없다면 커넥션을 다시 맺고 한번 더 전송을 시도해야 한다.
• 파이프라인커넥션의 경우 커넥션이 갑자기 끊기게 될때 얼마만큼의 요청이 처리되었는지 전혀 알 수 없기 때문에 주의해야 한다.
• 정적인 환경인 GET은 반복적인 상황에 데이터의 영향을 끼치지않지만, POST의 경우 주의해야한다.
• 비멱등인 메서드나 순서에 대해 에이전트가 재요청 할 수 있는 기능을 제공해도 자동으로 재시도하면 안된다.

우아한 Connection 끊기

전체 끊기와 절반 끊기

• 애플리케이션은 TCP 입력 채널과 출력 채널 중 하나만 끊거나 둘 다 끊을 수 있다.
• 전체 끊기
• → close( )를 호출하면 입출력 채널의 커넥션을 모두 끊는다.
• 절반 끊기
• → shutdown( )을 호출하면 입출력 채널 중 하나를 개별적으로 끊을 수 있다.

TCP 끊기와 리셋 에러

• 단순한 HTTP 애플리케이션은 전체 끊기만 사용 가능 하다. 하지만, 각기 다른 HTTP 클라이언트, Proxy, 서버와 통신하고 파이프라인 지속커텍션 사용시 예상치 못한 에러를 발생하는 것을 예방하기 위해 절반끊기를 사용해야 한다.
• 보통 출력 채널을 끊는 것이 안전하다.
• 클라이언트에서 데이터를 보내지 않을 것임을 확신하지 않는 이상 커넥션의 입력 채널을 끊는것은 위험하다.
  • ex) 10개의 요청을 파이프라인 지속 커넥션에 통해 전송하였고, 이미 응답은 운영체제 버퍼에 있지만, 아직 애플리케이션이 읽지 않은 상태에서 11번째 요청을 보냈는데 커넥션이 끊긴상태가 발생 할 수 있다.
  • 따라서, connection reset by peer 메세지가 발생 할 수 있다.
    • connection reset by peer
    • → 연결이 끊긴 커넥션에 데이터가 도착하게 되면 발생하는 에러

우아하게 커넥션 끊기

• 일반적으로 애플리케이션의 출력채널을 먼저 끊고 다른쪽에 있는 기기의 출력채널이 끊기는 것을 기다리는 것
  • 양쪽에서 더는 데이터를 전송하지 않을 것이라는 것을 알려주면 커넥션은 리셋 위험없이 종료된다.
• 하지만, 안타깝게도 상대방이 절반끊기를 했다는 보장도 없고 해주었는지 검사해준다는 보장도 없다.
  • 따라서, 절반끊기를 한 후 데이터나 스트림의 끝을 실병하기 위해 입력 채널에 대해 상태 검사를 주기적으로 해주어야 한다. 만약 입력 채널이 특정 타임아웃시간안에 끊어지지 않으면, 애플리케이션은 리소스 보호를 위해 스스로 커넥션을 강제로 끊을 수 있다.