2. TCP?
전송 제어 프로토콜(Transmission Control Protocol, TCP)은 인터넷 프로토콜 스위트(IP)의
핵심 프로토콜 중 하나로, IP와 함께 TCP/IP라는 명칭으로도 널리 불린다.
TCP는 근거리 통신망이나 인트라넷, 인터넷에 연결된 컴퓨터에서 실행되는 프로그램 간에
일련의 옥텟을 안정적으로, 순서대로, 에러없이 교환할 수 있게 한다.
TCP는 전송 계층에 위치한다.
네트워크의 정보 전달을 통제하는 프로토콜이자 인터넷을 이루는 핵심 프로토콜의
하나로서 국제 인터넷 표준화 기구(IETF)의 RFC 793에 기술되어 있다.
http://goo.gl/qk9Izg
3. Socket 라이브러리 리졸버
네트워크 애플리케이션
(웹 브라우저, 메일러, 웹 서버, 메일 서버 등)
IP
(패킷 운반, 경로 결정) ARP
프로토콜 스택
TCP
(커넥션 사용)
UDP
(커넥션 사용하지 않음)
ICMP
LAN 드라이버 (LAN 어댑터 제어)
LAN 어댑터
애플리케이션
OS
소프트웨어
드라이버
하드웨어
* TCP : Transmission Control Protocol
* UDP : User Datagram Protocol
* IP : Internet Protocol
* ICMP : Internet Control Message Protocol
* ARP : Address Resolution Protocol
TCP/IP는 계층구조!
위의 계층이 아래 계층에
작업을 의뢰하도록 되어 있다.
4. 서버에 접속?
서버클라이언트
1. 소켓을 만든다.
2. 브라우저는 URL을 바탕으로 서버의 IP주소 조사
3. 포트번호는 80번 사용 ( web 기준 )
4. 클라이언트의 IP주소나 포트 번호를 서버측에 알림
1. 소켓은 이미 만들어져 있다.
2. 클라이언트의 요청을 기다린다.
3. 클라이언트 요청이 들어오면
소켓을 연결하여 데이터를 주고 받는다.
5. (a) 데이터를 저장한 패킷
..…
데이터
조각
TCP의
제어정보
이더넷이나
IP의 제어 정보
애플리케이션의 데이터
패킷 진행 방향
패킷 전체
애플리케이션의 데이터를 송・수신할 경우의 패킷 모습
(b) 제어 정보만 있는 패킷
제어 동작이나 연결 끊기 동작 등 애플리케이션의 데이터가
없는 경우에는 제어 정보만 주고받는데, 이때의 패킷 모습
TCP의
제어정보
이더넷이나
IP의 제어 정보
패킷 진행 방향
6. 데이터를
송・수신 한다!
• 데이터를 송신하는 방법은 다양하다.
ex) 한꺼번에 전부 전송, 1바이트씩 전송, 1행씩 전송 등.
• 작은 패킷을 자주 보낼 경우, 네트워크 이용 효율이 저하된다.
→ 어느 정도 저장한 후 송・수신 동작을 수행.
7. 프리앰블(preamble) /
스타트 프레임 딜리미터
버퍼 진행 방향
이부분의
최대 길이가 MSS
* MTU(Maximum Transmission Unit)
- 패킷 한 개로 운반할 수 있는 디지털 데이터의 최대 길이, 이더넷에서는 보통 1,500바이트
* MSS(Maximum Segment Size)
- 헤더를 제외하고 한 개의 패킷으로 운반할 수 있는 TCP의 데이터의 최대 길이
FCS데이터TCP 헤더IP 헤더MAC 헤더
이부분의 최대 길이가 MTU
(이더넷에서는 1,500바이트)
8. 데이터를 송・수신 한다!
• 애플리케이션에서 받은 데이터가 MSS를 초과하거나
MSS에 가까운 길이에 이르기까지 데이터를 저장한 후 송신 동작을 수행.
➥ 패킷이 잘게 나누어질 걱정을 할 필요가 없다.
• MSS에 가깝게 데이터를 저장하면 시간이 걸려 송신 동작이 지연.
➥ 일정 시간 이상 경과하면 패킷을 송신한다. (프로토콜 스택의 내부 타이머에 의한 동작)
이에 대해 TCP/IP 프로토콜 사양에는 절충에 관한 규정은 없다 ! (개발자 마음대로^^)
10. HTML 헤더 메시지 본문
애플리케이션의 데이터
조각2TCP
조각2TCPIPMAC
조각1TCP
조각1TCPIPMAC
TCP가 조각으로 분할하여 헤더 부가
IP 헤더 부가
…..
…..
패킷 진행 방향
MSS의 크기 MTU의 크기
* MSS : Maximum Segment Size
* MTU : Maximum Transmission Unit
클 때는 나누는게 최고!
11. ACK라는 것이 있지요!
ACK는 송신측에 대하여 수신측에서 긍정 응답으로 보내지는 전송 제어용 캐릭터
ACK 번호를 사용하여 패킷이 도착했는지 확인한다.
→ 송신한 패킷이 제대로 도착하지 않았으면 재송신을 요구해요.
[acknowledge]
12. 시퀀스 번호 : 1, 크기 : 1,460바이트
ACK 번호 : 1,461
시퀀스 번호 : 1,461, 크기 : 1,460바이트
ACK 번호 : 2,921
시퀀스 번호 : 2,921, 크기 : 1,460바이트
ACK 번호 : 4,381
송신측 수신측
데
이
터
분
할
이 값을 시퀀스
번호로 설정
맨 앞부터 세어
1번째 바이트
맨 앞부터 세어
1,461번째 바이트
맨 앞부터 세어
2,921번째 바이트
애플리케이션
데이터
데
이
터
조
립
이 값에 1을 더한 값을
ACK 번호로 설정
1,460번째 바이트
까지 수신 완료
2,920번째 바이트
까지 수신 완료
4,380번째 바이트
까지 수신 완료
수신 확인 응답
실제로 시퀀스 번호는 난수를 바탕으로
산출한 초기값으로 시작한다. (악성 공격 예방)
14. 서버 클라이언트
클라이언트측의 시퀀스 번호 초기값
서버측의 시퀀스 번호 초기값
클라이언트측 시퀀스 번호
서버측의 ACK 번호
서버측의 시퀀스 번호
클라이언트측의 ACK 번호
…..…..
서버에서 클라이언트에게
보내는 데이터
클라이언트에서 서버에
보내는 데이터
클라이언트에서 서버에
도착한 데이터
서버에서 클라이언트에
도착한 데이터
…..
…..
…..
…..
15. 서버 클라이언트
시퀀스 번호 + 데이터
ACK 번호
시퀀스 번호 + 데이터
ACK 번호
......
송・수신 동작
시퀀스 번호 초기값
ACK 번호 접속 동작
ACK 번호
시퀀스 번호 초기값
: 클라이언트에서 서버에
보내는 데이터에 관한 것
: 서버에서 클라이언트에
보내는 데이터에 관한 것
16. ACK번호의 대기시간?
대기 시간은 너무 짧지도, 길지도 않은 적절한(?) 값이어야 한다.
TCP는 대기 시간을 동적으로 변경.
ACK 번호가 돌아오는 시간을 기준으로 대기시간을 판단한다.
17. ACK번호가 늦게 오면
마냥 기다려야 돼요??
윈도우 제어 방식에 따라 효율적으로 ACK 번호를 관리한다.
➥ 한 개의 패킷을 보낸 후 ACK 번호를 기다리지 않고 차례대로
연속해서 복수의 패킷을 보내는 방법
18. (a) 핑퐁 방식 (b) 윈도우 제어 방식
서버
클라이언트
ACK 번호를
기다리는
시간이 낭비됨
서버
클라이언트
ACK 번호를
기다리는 사이
다음 송신을 하므로
낭비가 없음
시간의
경과
시간의
경과
19. 능력의 한계;;를 느낄 때!
1. 수신측 TCP는 패킷을 수신하면 수신용 버퍼 메모리에 일시 보관.
2. 수신측에서 ACK 번호를 계산하여 조각 데이터를 복원후 애플리케이션에 전달.
3. 처리가 끝나지 않았을 때 도착한 데이터는 버퍼에 일시 보관.
if (애플리케이션에 건네주는 속도 < 데이터 도착 속도) {
응 ??
}
20. 수신측
송신측
4380 2920 1460 0 1460 02920
빈 영역이 0이 되면
송신 중지
보낸 데이터만큼
빈 영역에서 뺌
수신용 메모리의
빈 영역
데이터를 2,920
바이트만큼 추출 수신측
프로그램
수신용 메모리 영역
(4,380바이트)
알려줌 다시
알려줌
22. に
UDP
TCP
중개 외엔 아무것도 안해
아직 도착 안했어
다시 한번 보내줘
데이터를 확실히 송・수신
송・수신 속도를 조절
Fig1. http://goo.gl/9Eeid0
UDP : User Diagram Protocol
DNS 서버에 대한 조회 등에서 짧은 제어용 데이터를 송・수신할 경우
음성이나 동영상 데이터를 수신할 경우
TCP : Transmission Control Protocol
브라우저나 메일 등의 일반적인
애플리케이션이 데이터를 송・수신할 경우
23. 이제 TCP, 믿을 수 있겠죠?
[Reference]
[1] “성공과 실패를 결정하는 1%의 네트워크 원리”, Tsutomu Tone, 성안당.
[2] “윤성우의 열혈 TCP/IP 소켓 프로그래밍”, 윤성우, 오렌지미디어.
[3] “뇌를 자극하는 TCP/IP 소켓 프로그래밍”, 윤상배, 한빛미디어.
[4] http://itpro.nikkeibp.co.jp/article/lecture/20070305/263897/