▲

GN⁺: 프로그래머들이 믿는 잘못된 TCP 정보

 (lwn.net)
3P by neo 2달전 | favorite | 댓글 1개

NetworkManager 또는 networkd

  • NetworkManager 또는 networkd

    • 사용자는 wpa_supplicant 기반 관리로 전환한 이유를 설명함
    • TCP에 대한 잘못된 믿음 목록을 제시함
    • TCP의 신뢰성에 대한 오해를 다룸

  • TCP에 대한 잘못된 믿음 목록

    • TCP는 항상 신뢰할 수 있음
    • TCP는 대부분 신뢰할 수 있음
    • TCP는 신뢰할 수 없지만, 송신자와 수신자는 결국 전송된 바이트에 대해 합의할 것임
    • TCP 위에 메시지 지향 프로토콜을 구축하면 신뢰성을 보장할 수 있음
    • TCP 패킷이라는 것이 존재함
    • TCP 패킷이라는 것이 존재하지 않음
    • 원격 호스트에 연결 실패 시, 오프라인 상태임
    • Nagle 알고리듬은 좋음
    • Nagle 알고리듬은 나쁨
    • Nagle 알고리듬에 신경 쓸 필요가 없음
    • TCP는 네트워크를 투명하게 처리함
    • 네트워크가 TCP에 투명하면 IP에도 투명함
    • 네트워크가 HTTP/1.1에 투명하면 TCP에도 투명함
    • 표준 프로토콜에 투명하지 않은 네트워크는 예외적임
    • TCP는 IP를 기반으로 구현됨

  • 설명

    • ACK가 대기 중일 때 연결이 끊어지면 송신자는 세그먼트가 수신되었는지 알 수 없음
    • Paxos 또는 Raft와 같은 알고리듬이 필요하며, 최소 세 개의 노드가 필요함
    • SMTP와 같은 프로토콜에서도 이 문제가 발생함

  • 추가 의견

    • 두 당사자가 불확실한 링크를 통해 합의에 도달할 수 있음
    • 전송된 바이트의 하위 집합에 대해 합의할 수 있음
    • 합의된 바이트 집합이 0일 수 있으며, 이는 증가할 수 있음
    • Paxos가 필요하지 않음

  • 추가 논의

    • 합의된 바이트 집합의 정확한 범위를 알 수 없음
    • 네트워크 투명성에 대한 잘못된 믿음이 문제를 일으킴
    • ICMP를 차단하거나 이해하지 못하는 패킷을 드롭하는 네트워크가 있음
    • 혼잡 제어에 대한 지식이 필요함

GN⁺의 정리

  • 이 기사는 TCP의 신뢰성에 대한 잘못된 믿음을 다루며, 네트워크 관리 도구의 선택에 대한 논의를 포함함
  • TCP의 신뢰성 문제는 Paxos와 같은 복잡한 알고리듬이 필요함을 설명함
  • 네트워크 투명성에 대한 잘못된 믿음이 실제 문제를 일으킬 수 있음을 강조함
  • 네트워크 관리 도구 선택 시 고려해야 할 다양한 요소를 제시함
▲
neo 2달전  [-]
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 문제를 겪고 있을 것임
답변달기