일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- silver
- 완전탐색
- 카카오
- 영화
- 코딩 테스트
- review
- 넷플릭스
- coding
- BFS
- Netflix
- kakao
- 추천
- 리뷰
- array
- BOJ
- 백준
- Recursive
- health
- parametric search
- 나는솔로
- 영어
- 알고리즘
- Greedy
- 해설
- 수능
- usaco
- benefits
- Movie
- 2020
- Algorithm
- Today
- Total
Young
TCP / IP 본문
internet 상에서 사용하는 communication protocol이 여러 개 있는데, 이 중 가장 많이 사용하는 것은 TCP/IP 입니다.
아래 그림을 보면, 데이터가 전송될 때 전송 계층의 'TCP'와 네트워크 계층의 'IP'를 이용합니다.
각 계층에는 많은 통신 규약이 있는데, 이 두 가지의 조합을 이용합니다.
그래서 두 개의 다른 프로토콜을 붙여서 하나의 프로토콜처럼 TCP/IP 라고 말합니다.
계층을 내려가면서, 각 계층에서 header를 붙여 전송하게 됩니다.
IP header, TCP header 등을 붙입니다.
receiver 쪽에서 이 header를 반대로 하나씩 떼어가면서 마지막에 데이터를 읽게 됩니다.
1. 데이터를 보내는 전반적인 과정을 한 번 보자
sender가 1GB의 데이터를 보낸다고 하자.
1GB를 하나의 message에 실어서 보내는게 아니다. 이를 작은 단위로 쪼개서 보내게 된다.
1GB를 쪼갠 후, 각 데이터마다 원래 데이터에서의 순서를 적어 놓는다.
그렇게 되면 순서대로 도착하지 않은 데이터를 receiver에서 데이터를 올바로 조립할 수 있게 된다.
또 다른, 이유로 receiver에서 4번 데이터를 받았다면, sender에게 ACK이라는 것을 보내게 된다.
즉, '나 4번 데이터 잘 받았음!' 이라는 뜻이다.
이렇게 유실없이 데이터를 모두 받을 수 있게 된다.
2. 이 과정에서 생기는 문제점과 더 자세한 과정을 보자
(1) 신뢰성 있는 데이터 전송
어떻게 유실없이 데이터를 전송할 수 있는지를 알아보자.
4번 데이터를 보내고, receiver가 이를 잘 받았다면 ACK를 보내게 된다.
ACK message 안에 '4번 데이터 잘 받았음' 이라고 쓰고 보낸다.
sender는 이 message를 받으면 4번 데이터를 잘 받았구나라고 인식하게 됩니다.
만약 보낸 4번 데이터에 대한 일정시간 안에 ACK를 받지 못했다면,
sender는 4번 데이터를 재전송하게 됩니다.
(2) handshake
TCP는 connection-oriented 라고 합니다.
(3) 데이터 전송 속도 제한
데이터를 전송하는 속도를 한없이 높일 수 없다.
여기에는 크게 두 가지 이유가 있다.
- 모든 sender가 높은 속도로 데이터를 보내게 되면, 네트워크 정체가 발생하기 때문이다.
- receiver가 들어온 데이터를 처리하는 속도에 한계가 있고, 이를 잠시 저장해두는 buffer 사이즈에 제한이 있기 때문이다.
여기에서 등장하는 개념은 window 이다.
receiver 쪽에서 자기가 한 번에 얼만큼의 데이터를 받을 수 있는지 sender 쪽에 알려주게 되면
sender는 이를 window 크기로 설정한다. 이 한 번에 최대 설정한 window 크기 만큼만
보낸다. 이것이 'receive window'이다. (flow control)
네트워크 정체를 컨트롤하기 위해 설정하는 window가 있다. 이것이 'congestion window'이다.
(congestion control)
'Web' 카테고리의 다른 글
HTTP 란? (0) | 2020.10.04 |
---|---|
HTTP, TCP, IP 란? (0) | 2020.10.04 |
reactive (0) | 2020.10.01 |
gRPC (0) | 2020.10.01 |
RPC (Remote Procedure Call) (0) | 2020.09.30 |