VOS 17.1 STCP 이전에는 서버 응용 프로그램이 수락 함수를 호출하지 않는 한 TCP 연결 요청을 수락하지 않습니다. 연결 요청은 백로그 큐에 배치되었지만 수락 호출이 백로그 큐에서 요청을 제거할 때까지 응답이 전송되지 않았습니다. 백로그 큐가 채워지면 STCP는 연결 요청에 대한 응답으로 재설정을 보냅니다.
릴리스 17.1부터 TCP 연결의 역학이 변경되었습니다. 이제 백로그 큐가 채워지지 않았다고 가정하면 연결 요청이 들어오면 STCP 스택이 즉시 연결을 수락하는 응답을 보냅니다. 그런 다음 연결이 백로그 큐에 배치됩니다. 백로그 큐가 후속 연결 요청을 채우면 응답을 보내지 않습니다. 서버 응용 프로그램 호출이 백로그 큐 앞의 연결을 수락하면 제거됩니다. 이제 이 동작은 대부분의 다른 운영 체제에서 TCP 스택이 동작하는 방식과 유사합니다.
정상적인 상황에서이러한 역학 변경으로 인해 서버 또는 클라이언트 응용 프로그램의 행동 방식이 눈에 띄는 변화가 되지는 않습니다. 그러나 서버 응용 프로그램이 느려지거나 연결이 예상보다 빠르게 들어오는 경우 연결이 장시간 백 로그 큐에 남아 있을 수 있습니다. 이러한 상황에서 몇 가지 흥미로운 행동을 발견 할 수있다.
다음 표에서는 클라이언트의 작업을 기반으로 백로그 큐에 연결 요청이 배치될 때 발생하는 작업에 대한 요약을 제공합니다. 클라이언트는 서버 응용 프로그램이 데이터를 보낼 때까지 기다리거나 데이터를 보낼 때까지 기다리거나 데이터를 보낼 수 있으며/또는 FIN(최종) 플래그(일반 닫기) 또는 RST(재설정) 플래그(비정상적인 닫기)로 연결을 닫을 수 있습니다. 처음 4개의 열은 예상대로 행동합니다. 서버 응용 프로그램은 백로그 큐에서 소켓을 가져오는 것을 수락한 다음 recv를 호출하고 데이터가 없거나 소켓에 있는 내용에 따라 데이터 및/또는 파일 표시 끝을 가져오는 경우 중단됩니다. 더 자세히 살펴봐야 할 마지막 4개의 열입니다.
소켓에 있는 없음 | 소켓의 데이터 | 소켓에 FIN | 소켓의 데이터/
소켓에 FIN |
소켓의 데이터/
소켓에 FIN / 클라이언트 소켓 사라 |
소켓에 FIN /
클라이언트 소켓 사라 |
소켓의 데이터/
전송된 재설정 |
보내기 재설정 | ||
받아들일 | 소켓 반환 | 소켓 반환 | 소켓 반환 | 소켓 반환 | 소켓 반환 | 소켓 반환 | 중단 | 중단 | |
첫 번째 recv | 중단 | 데이터 반환 | EOF 반환 | 데이터 반환 | 재설정 오류 반환 | EOF 반환 | |||
두 번째 Recv | 중단 | EOF 반환 |
소켓 / FIN의 소켓 / 클라이언트 소켓의 데이터는 사라졌습니다.
이 시나리오에서 클라이언트는 일부 데이터를 전송하고 연결을 종료했습니다. STCP의 17.1 릴리스는 전송된 모든 데이터를 인정하지만 수신 큐의 데이터가 응용 프로그램에 전달될 때까지 FIN을 인정하지 않습니다. 따라서 클라이언트의 재전송 타이머가 만료될 때까지 클라이언트의 FIN이 다시 전송됩니다. 잘 작성된 클라이언트 응용 프로그램은 FIN 시간이 꺼지면 클라이언트가 오류를 통보받을 수 있도록 서버 응용 프로그램이 연결의 측면을 종료할 때까지 기다립니다. 그러나 클라이언트 응용 프로그램이 서버에서 표시를 기다리지 않고 소켓을 닫으면 전송된 데이터가 손실되었을 수 있음을 알 수 없습니다.
서버 응용 프로그램에서 호출하면 중복 승인 패킷을 수락하여 데이터를 인정하지만 FIN이 전송되지 는 않습니다. 클라이언트가 소켓을 분해한 이후 재설정으로 응답합니다. 재설정은 서버 측의 소켓을 지웁구나합니다. 서버 응용 프로그램은 수락할 호출 시간과 첫 번째 recv호출 사이의 시간에 따라 recv에 대한 첫 번째 또는 두 번째 호출에서 재설정 오류가 발생합니다. 해당 시간이 클라이언트의 재설정 패킷을 얻고 처리하는 데 걸리는 시간보다 빠르면 서버 응용 프로그램이 데이터를 볼 수 있습니다. 두 경우 모두 서버 응용 프로그램은 연결이 이루어졌으며 연결이 중단되었음을 알 수 있습니다.
소켓 / 클라이언트 소켓에 FIN사라
이는 소켓에 데이터가 없다는 점에서 이전 시나리오와 다릅니다. 데이터가 없는 경우 FIN이 인정됩니다. 수락은 소켓을 반환하고 recv는 FIN을 받은 것을 나타내는 EOF를 반환합니다. 소켓에 쓰기를 시도하면 닫는 것을 포함하여 클라이언트에 해당 소켓이 더 이상 없기 때문에 재설정이 반환됩니다.
소켓/리셋 전송된 데이터
여기서 클라이언트는 일부 데이터를 보낸 다음 리셋을 보냅니다. 재설정에는 여러 가지 이유가 있을 수 있습니다. 일반적인 하나는 응용 프로그램이 소켓을 종료하고 TCP 스택은 즉시 리셋을 보내거나 FIN 패킷에 대한 승인을 얻지 못한 후 재설정을 보내는 것입니다. 이는 첫 번째 시나리오와 비슷하지만 클라이언트의 TCP 스택은 소켓을 분해하는 대신 소켓을 분해하기 전에 리셋을 보냅니다. 다시 말하지만, 잘 작성된 클라이언트 응용 프로그램은 이것을 오류로 볼 수 있습니다. 잘 작성되지 않은 응용 프로그램은 오류가 표시되지 않습니다.
서버 소켓이 해제되고 재설정이 수신될 때 모든 데이터가 삭제되므로 서버 응용 프로그램에서 연결이 설정된 표시도 표시되지 않습니다. 그것은 단지 다른 연결을 기다리고 중단.
전송된 재설정
다시 재설정하면 백로그 큐에서 소켓을 효과적으로 제거하여 수락이 표시되지 않고 다른 연결 요청을 기다립니다.
그렇다면 이 모든 것이 실제로 무엇을 의미할까요? 첫째, 클라이언트 응용 프로그램은 이제 더 빠른 연결 응답을 얻을 수 있지만 응용 프로그램 수준 배너 또는 메시지의 모든 종류를 더 오래 기다려야 할 수 있습니다. 이 배너/메시지에 대한 모든 시간 시간은 위쪽으로 조정해야 할 수 있습니다. 둘째, 서버 응용 프로그램은 수락을 수행한 직후 recv 호출에서 오류를 처리할 수 있도록 준비해야 합니다. 이것은 항상 가능성이었지만 확률은 이제 더 큽습니다. 마지막으로 서버에 데이터를 전송하고 어떤 종류의 메시지를 다시 기대하지 않는 클라이언트 응용 프로그램은 서버 응용 프로그램이 연결을 올바르게 종료했거나 무의식적으로 데이터를 잃어야 할 위험이 있는지 확인하기 위해 작성되어야 합니다. 다시 말하지만,이 가능성은 항상 존재하고 STCP고유하지 않지만 아마 지금은 약간 더 큽다.