Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
Tags
- PETERICA
- 코틀린 코루틴의 정석
- 공부
- Claude
- LLM
- Spring
- Java
- SRE
- kotlin coroutine
- 티스토리챌린지
- aws
- kotlin
- Kubernetes
- golang
- CKA 기출문제
- 오블완
- Rag
- 기록으로 실력을 쌓자
- 바이브코딩
- CKA
- docker
- go
- AWS Network
- AWS EKS
- AI
- 정보처리기사 실기 기출문제
- tucker의 go 언어 프로그래밍
- MySQL
- aws vpc
- Network
Archives
- Today
- Total
목록Advertised Window (1)
피터의 개발이야기
[Network] 18. 받는 사람이 감당하지 못할 만큼 보내면 어떻게 될까?
목차: [Network] TCP/IP를 우편 시스템으로 이해하기TCP/IP를 우편 시스템으로 이해하기 — Part 5. 믿을 수 없는 길 위에서 믿을 수 있게 보내기ㅁ 들어가며TCP는 잃어버린 Byte를 찾아 다시 보낼 수 있다.그렇다고 확인 응답이 오기 전에 Data를 무제한으로 보내도 되는 것은 아니다.받는 Application이 천천히 읽으면 Receiver의 Memory Buffer가 가득 찬다.양쪽 Computer가 충분히 빨라도 중간 Router로 Packet이 한꺼번에 몰리면 Queue가 넘친다.겉으로는 둘 다 “Sender가 너무 빨리 보냈다”는 문제처럼 보인다. 그러나 보호해야 할 대상이 다르다.Receiver가 감당하지 못함→ Flow Control→ Receive Window(rwnd..
DevOps/Network
2026. 7. 20. 20:18