Hacker News 의견

• "falsehoods programmers believe" 형식이 명확하지 않아 혼란스러움

  • TCP 패킷의 존재 여부에 대한 논쟁이 이해되지 않음
  • 철학적 혼란을 일으키는 내용임

• Ethernet 케이블을 뽑았다가 다시 연결해도 연결이 유지되는 것에 놀라움

  • TCP는 폭탄이 떨어져도 작동하도록 설계됨

• "at most once" 또는 "at least once" 전달 보장이 가능하지만 "exactly once" 전달 보장은 불가능함

  • 많은 주니어 개발자들이 "exactly once" 전달 보장이 없으면 버그라고 생각함

• ACK가 outstanding 상태에서 연결이 끊기면 송신자는 세그먼트가 수신되었는지 알 수 없음

  • TCP는 양방향 파이프를 제공하며, 정확한 전달 보장은 애플리케이션의 책임임
  • HTTP 요청이 응답을 받기 전에 중단되면 송신자는 요청이 서버에 도달하지 않았다고 가정하고 새로운 연결로 다시 시도해야 함

• 오류 수정 코드에 대해 들어본 적이 없는지 의문임

  • TCP 또는 Ethernet 프레임에 FEC 바이트가 포함되어 있음
  • HTTP over TLS는 암호화된 데이터 프레임을 사용하며, 데이터 손실이 발생하면 수신 불가능함
  • 많은 현대 인터넷이 이 패러다임에 기반하고 있음

• 데이터센터 내부에서 자체 하드웨어를 사용할 때는 저수준의 세부 사항을 무시할 수 있음

  • 대역폭 제한, 패킷 RPS 제한, 지연 시간은 여전히 중요함

• 이 기사는 완성된 글이 아니며, HN 제출 제목이 오해를 불러일으킬 수 있음

• VKontakte에서 일할 때 해결하려던 문제를 상기시킴

  • 지하철에서 메시지를 보내면 서버에 도달하지만 응답이 도착하기 전에 신호가 끊김
  • 클라이언트가 메시지 전송 실패로 인식하고 다시 시도함
  • 클라이언트 생성 "랜덤 ID"를 사용하여 문제 해결
  • Telegram은 클라이언트가 서버에 재연결할 때 이전 연결 동안 확인되지 않은 모든 응답을 전송함

• 많은 사람들이 TCP가 함수 호출이 아니라는 것을 이해하지 못함

  • 최근에 새로운 TCP 속도 제한기가 매우 잘못된 상태로 나왔음
  • 대부분의 컨테이너가 Bufferbloat 문제를 겪고 있을 것임