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
- 플러터
- riverpod
- 유데미
- copyWIth
- 유데미 코리아
- 가상환경
- linux
- command
- dart
- 개발자
- 리눅스
- 디자인패턴
- 책
- flutter
- 파이썬
- ExpansionTile
- python
- ListTile
- 개발
- 프로그래밍
- 다트
- 유데미 러닝크루
- 명령어
- 맥
- Code Generation
- vscode
- 도서
- 리버팟
- freezeD
- 코딩
Archives
- Today
- Total
승상의 코딩 블로그
TCP 연결 종료 과정 본문
통신 프로토콜에 대한 이해는 통신에 대한 이해도를 높여주고 디버깅 시에 유용하게 쓰인다.
TCP 연결 종료 과정도 디버깅 시에 유용하게 쓰일 수 있다.
연결 종료 단계
일단은 TCP 가 어떻게 연결 종료되는지를 알아보자.
A, B 두 프로그램이 TCP 통신을 하고 있다고 하자.
A 가 연결 종료를 먼저 요청했다고 가정한다.
- A 에서 FIN 패킷을 보낸다.
- B 에서 A 의 FIN 패킷에 대한 ACK 패킷을 보낸다.
- B 에서도 FIN 패킷을 보낸다. (B 도 연결 종료를 요청)
- A 는 B의 FIN 패킷에 대한 ACK 패킷을 보낸다. 이 때, 2MSL(Maximum Segment Lifetime) 만큼 대기한다.
- 2MSL (1~4분 정도) 를 대기하는 이유는 A -> B 로의 마지막 ACK 가 정상적으로 전송됨을 보장하기 위함이다.
누락될 경우 연결 종료를 위한 패킷을 다시 보낸다.
- 2MSL (1~4분 정도) 를 대기하는 이유는 A -> B 로의 마지막 ACK 가 정상적으로 전송됨을 보장하기 위함이다.
연결 종료 단계의 TCP 상태
- FIN_WAIT_1 : FIN 패킷(A->B)에 대한 ACK 를 대기하는 상태
- FIN_WAIT_2 : 첫번째 FIN 패킷(A->B)에 대한 ACK 를 받은 이후 두번째 FIN 패킷(B->A)을 받을 때까지 대기하는 상태
- TIME_WAIT : 마지막 ACK(B->A) 이 정상적으로 전송되기 위해 대기하는 상태 (패킷 전송 실패시 재전송 시간을 보장하기 위함)
- CLOSE_WAIT : 첫번째 ACK (B->A) 이후 프로그램이 정상 종료되기까지 대기하는 상태
- LAST_ACK : 두번째 FIN(B->A) 패킷전송이후 마지막 ACK 를 대기하는 상태
- CLOSED: 종료된 상태
각 연결 상태는 아주 순식에 사라진다. 하지만 TIME_WAIT 의 상태는 netstat 명령어로 확인이 가능하다.
이를 활용하면 누가 먼저 연결을 종료했는지 확인할 수 있다. (* 정상적인 연결종료상태일 경우)
개인적으로 생각보다 자주 썻다. 기억하고 잘 활용해보자.
반응형
'잡다한 지식' 카테고리의 다른 글
동일 네트워크에서 파이썬을 활용한 파일공유 방법 (0) | 2024.12.03 |
---|---|
회사에서 메일 작성하는 방법 (2) | 2024.09.18 |
[Mac 단축키] VSCode 에서 뒤로가기 앞으로가기 단축키(마우스 펑션키 없을 때) (0) | 2024.07.28 |
[Mac 앱 추천] Rectangle - 맥 화면분할 앱/ 코딩 공부환경 필수 앱 (0) | 2024.07.06 |
[Mac 앱 추천] GIPHY Capture - 맥 화면 녹화(GIF) 앱/ 코딩 공부기록 필수 앱 (0) | 2024.07.06 |
Comments