"응용 프로그램은 몇 년 동안 잘 실행되었습니다, 지난 주 네트워크가 업그레이드하고 우리는 기가 비트에 100 mbps의 Mbps로 이동. 이제 일부 메시지의 데이터의 마지막 절반은 가비지입니다. 네트워크 사람들은 네트워크가 아니라고 맹세하지만, 이것이 유일한 변화입니다."
좋은 소식은 고가의 네트워크 업그레이드가 응용 프로그램을 중단하지 않았다는 것입니다.
나쁜 소식은 응용 프로그램이 고장났으며 항상 고장났다는 것입니다. *많은* TCP 응용 프로그램을 작성하는 사람들은 TCP가 메시지가 아닌 바이트스트림이라는 것을 깨닫지 못합니다. 응용 프로그램이 두 개의 1000 바이트 메시지를 보낸다는 사실은 전송 TCP 스택이 두 개의 1000 바이트 TCP 세그먼트를 보낼 것을 의미하지 는 않습니다. 응용 프로그램 메시지는 수신기의 광고 최대 세그먼트 크기 또는 보낸 사람의 일부 구성 제한에 따라 더 작은 조각으로 분할할 수 있습니다. 다시 전송은 응용 프로그램 메시지를 결합하고 조각할 수도 있습니다. 송신 TCP 스택이 실제로 두 개의 1000 바이트 TCP 세그먼트를 보내더라도 수신 TCP 스택이 수신 응용 프로그램에 두 개의 1000 바이트 메시지를 줄 것이라는 보장은 없습니다. 예를 들어 응용 프로그램의 버퍼가 500바이트에 불과한 경우 모든 TCP 스택이 반환됩니다. 반면에 버퍼가 1500바이트이고 1000바이트 세그먼트가 모두 도착한 경우 TCP 스택은 첫 번째 호출에서 1500바이트, 두 번째 호출에서는 500바이트를 반환합니다. 바이트 스트림을 가져 와서 올바르게 다시 메시지로 구문 분석하는 것은 응용 프로그램에 달려 있습니다.
이는 네트워크 업그레이드와 관련이 있습니까? 그럼 OpenVOS 서버와 리눅스 클라이언트 어디 다른 서브넷에 그래서 OpenVos 시스템은 536 바이트의 최대 세그먼트 크기를 광고 했다. 클라이언트가 보낸 응용 프로그램 메시지는 1000바이트이므로 2개로 분할되는 메시지입니다. 업그레이드하기 전에 응용 프로그램이 수신을 게시하기 전에 두 세그먼트가 OpenVOS 서버에 도착한 것으로 나타나므로 수신 함수에 대한 한 번의 호출로 1000바이트를 모두 읽었습니다. 업그레이드 후 세그먼트 타이밍이 변경되어 응용 프로그램이 수신을 게시할 때 첫 번째 세그먼트만 사용할 수 있었습니다. 응용 프로그램 버퍼의 마지막 464(1000 ~ 536바이트)는 TCP 스택에 의해 채워지지 않았으며 수신이 게시되기 전에 거기에 있던 모든 쓰레기를 포함하였다.
이 경우 쉽게 빠른 수정이 있었고 OpenVOS의 광고된 MSS 값을 1460으로 증가시켰습니다(서브넷에서 TCP 처리량을 쉽게 개선할 수 있는 방법 참조). 그러나 그것은 정말로 정지 격차일 뿐입니다. 실제 해결책은 1 수신 호출이 1 개의 메시지를 반환한다고 가정하는 대신 TCP 바이트 스트림을 응용 프로그램 메시지로 다시 정확하게 구문 분석하기 위해 코드를 다시 작성하는 것입니다.