# 프로그래머들이 믿는 잘못된 TCP 정보

> Clean Markdown view of GeekNews topic #16786. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=16786](https://news.hada.io/topic?id=16786)
- GeekNews Markdown: [https://news.hada.io/topic/16786.md](https://news.hada.io/topic/16786.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-09-16T09:47:46+09:00
- Updated: 2024-09-16T09:47:46+09:00
- Original source: [lwn.net](https://lwn.net/Articles/990281/)
- Points: 3
- Comments: 1

## Topic Body

##### 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와 같은 복잡한 알고리듬이 필요함을 설명함
- 네트워크 투명성에 대한 잘못된 믿음이 실제 문제를 일으킬 수 있음을 강조함
- 네트워크 관리 도구 선택 시 고려해야 할 다양한 요소를 제시함

## Comments



### Comment 28939

- Author: neo
- Created: 2024-09-16T09:47:46+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=41541770) 
- "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 문제를 겪고 있을 것임