TCP는 끝에서 끝까지 연결, 즉 한 호스트가 다른 호스트와 직접 통신하도록 지원하도록 설계되었습니다. 물론 그 사이에 는 다리와 라우터가 있었지만 이러한 장치는 TCP 헤더 또는 페이로드를 만지지 않았습니다. 그러나 더 이상 그렇지 않습니다. 이제 네트워크 주소 번역기, 방화벽, 침입 방지 시스템 및 네트워크 가속기와 같은 것들이 있습니다. 이러한 모든 것들은 TCP 헤더를 수정하거나, 승인서를 보내거나 재설정하거나, 패킷을 비트 버킷에 떨어뜨릴 수 있습니다. 설상가상으로 이러한 장치는 네트워크의 각 끝과 때로는 중간에 있습니다.
네트워크 Z에서 Y를 호스팅하는 연결이 있는 네트워크 B의 호스트 A의 사례를 상상해 보십시오. 네트워크 B 앞에는 호스트 Y의 승인을 스푸핑하여 처리량을 증가시키는 WAN 가속기가 있습니다. 이렇게 하면 호스트 A가 가능한 한 빨리 데이터를 보낼 수 있습니다. 가속기는 모든 버퍼링 및 재전송을 처리합니다. 불행하게도, 네트워크 Z 앞에 침입 방지 시스템은 호스트 A. Host Y에서 무고하지만 의심스러운 찾고 패킷을 삭제하고 그래서 그것을 인정하지 않습니다 그것을 볼 수 없습니다. 네트워크 B 앞에 있는 WAN 가속기는 다시 전송되지만 물론 패킷이 다시 삭제됩니다. 가속기는 결국 시간을 내고 다시 재설정하여 호스트 A및 호스트 Y로 보냅니다.
호스트 A의 시스템 관리자는 사용자가 불만을 제기 한 후 무슨 일이 일어나고 있는지 알아 내려고 할 때 무엇을 볼 수 있습니까? 그는 호스트 Y에서 호스트 Y하지만 호스트 Y에서 응용 프로그램 계층 응답이 없는 패킷을 남기고 Y호스트가 연결을 재설정하는 것을 보고, 문제가 나 호스트 Y가 연결을 재설정하는 이유를 나타내지 않습니다. 호스트 Y의 시스템 관리자는 무엇을 보나요? 그녀는 호스트 A가 패킷 전송을 중지한 다음 재설정을 보냈으며, 다시 아무 문제나 호스트 A가 연결을 재설정하는 이유를 나타내지 않는 것을 봅니다.
호스트 A가 호스트 Y와 직접 통신하고 있다는 가정이 잘못되어 각 관리자가 연결 오류에 대해 다른 시스템을 비난하게 됩니다.
무슨 일이 일어나고 있는지 알아내기 위해 IP 헤더 추적 데이터, "서비스 유형", ID, 플래그 및 "라이브 시간"(TTL)과 같은 필드에서 "흥미롭지 않은" 필드의 값에 주의를 기울여야 합니다. 이러한 필드의 변경 사항(예: 데이터가 있는 패킷은 47의 TTL이 있고 데이터가 없는 패킷에는 TTL이 127)이 있어 패킷이 두 개의 서로 다른 소스에서 유래하고 있음을 알 수 있습니다.
호스트 A와 호스트 Y의 추적을 비교하면 문제의 스포트 라이트가 빛날 수 있습니다. 다른 추적에 없는 하나의 추적에서 패킷을 볼 수 있을 뿐만 아니라 모든 흥미롭지 않은 IP 헤더 필드 또는 TCP 포트 또는 시퀀스 번호의 변경 사항은 이러한 호스트가 서로 직접 통신하지 않는다는 100% 확실성을 나타냅니다.
네트워크 가속기 또는 침입 방지 시스템을 해제하는 것은 불가능할 수 있지만(그리고 좋은 생각이 아닐 수도 있음) 그들이 무엇을 하고 있는지 아는 것은 문제가 발생할 때 문제를 이해하고 해결할 수 있는 더 나은 기회를 제공합니다.
회사