23
TCP, 믿을 수 있나요!? NHN NEXT 박용민 [2015.04.27]

[네트워크] TCP, 믿을 수 있나요!?

  • Upload
    -

  • View
    81

  • Download
    13

Embed Size (px)

Citation preview

TCP, 믿을 수 있나요!?

NHN NEXT

박용민

[2015.04.27]

TCP?

전송제어프로토콜(Transmission Control Protocol, TCP)은인터넷프로토콜스위트(IP)의

핵심프로토콜중하나로, IP와함께 TCP/IP라는명칭으로도널리불린다.

TCP는근거리통신망이나인트라넷, 인터넷에연결된컴퓨터에서실행되는프로그램간에

일련의옥텟을안정적으로, 순서대로, 에러없이교환할수있게한다.

TCP는전송계층에위치한다.

네트워크의정보전달을통제하는프로토콜이자인터넷을이루는핵심프로토콜의

하나로서국제인터넷표준화기구(IETF)의 RFC 793에기술되어있다.

http://goo.gl/qk9Izg

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는계층구조!위의계층이아래계층에작업을의뢰하도록되어있다.

서버에접속?

서버클라이언트

1. 소켓을만든다.2. 브라우저는 URL을바탕으로서버의 IP주소조사3. 포트번호는 80번사용 ( web 기준 )4. 클라이언트의 IP주소나포트번호를서버측에알림

1. 소켓은이미만들어져있다.2. 클라이언트의요청을기다린다.3. 클라이언트요청이들어오면

소켓을연결하여데이터를주고받는다.

(a) 데이터를저장한패킷

..…

데이터조각

TCP의제어정보

이더넷이나IP의제어정보

애플리케이션의데이터

패킷진행방향

패킷전체

애플리케이션의데이터를송・수신할경우의패킷모습

(b) 제어정보만있는패킷

제어동작이나연결끊기동작등애플리케이션의데이터가없는경우에는제어정보만주고받는데, 이때의패킷모습

TCP의제어정보

이더넷이나IP의제어정보

패킷진행방향

데이터를

송・수신한다!

• 데이터를송신하는방법은다양하다.

ex) 한꺼번에전부전송, 1바이트씩전송, 1행씩전송등.

• 작은패킷을자주보낼경우, 네트워크이용효율이저하된다.

→ 어느정도저장한후송・수신동작을수행.

프리앰블(preamble) /스타트프레임딜리미터

버퍼 진행 방향

이부분의최대길이가 MSS

* MTU(Maximum Transmission Unit)

- 패킷한개로운반할수있는디지털데이터의최대길이, 이더넷에서는보통 1,500바이트

* MSS(Maximum Segment Size)

- 헤더를제외하고한개의패킷으로운반할수있는 TCP의데이터의최대길이

FCS데이터TCP 헤더IP 헤더MAC 헤더

이부분의최대길이가 MTU(이더넷에서는 1,500바이트)

데이터를송・수신한다!

• 애플리케이션에서받은데이터가 MSS를초과하거나

MSS에가까운길이에이르기까지데이터를저장한후송신동작을수행.

➥ 패킷이잘게나누어질걱정을할필요가없다.

• MSS에가깝게데이터를저장하면시간이걸려송신동작이지연.

➥일정시간이상경과하면패킷을송신한다. (프로토콜스택의내부타이머에의한동작)

이에대해 TCP/IP 프로토콜사양에는절충에관한규정은없다 ! (개발자마음대로^^)

데이터를보내고싶어요!

HTML 헤더 메시지본문

애플리케이션의 데이터

조각2TCP

조각2TCPIPMAC

조각1TCP

조각1TCPIPMAC

TCP가조각으로분할하여헤더부가

IP 헤더부가

…..

…..

패킷 진행 방향

MSS의 크기 MTU의 크기* MSS : Maximum Segment Size* MTU : Maximum Transmission Unit

클때는나누는게최고!

ACK라는것이있지요!

ACK는송신측에대하여수신측에서긍정응답으로보내지는전송제어용캐릭터

ACK 번호를사용하여패킷이도착했는지확인한다.

→ 송신한패킷이제대로도착하지않았으면재송신을요구해요.

[acknowledge]

시퀀스번호 : 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번째 바이트까지 수신 완료

수신확인응답

실제로시퀀스번호는난수를바탕으로산출한초기값으로시작한다. (악성공격예방)

그런데,왜!!클라이언트에서 서버로만

데이터를보내나요?

데이터의흐름을하나만고려했기때문!

TCP의데이터송・수신동작은양방향이므로, 여기에대응해야한다.

서버 클라이언트

클라이언트측의시퀀스번호초기값

서버측의시퀀스번호초기값

클라이언트측시퀀스번호

서버측의 ACK 번호

서버측의시퀀스번호

클라이언트측의 ACK 번호

…..

…..

서버에서 클라이언트에게보내는 데이터

클라이언트에서 서버에보내는 데이터

클라이언트에서 서버에도착한 데이터

서버에서 클라이언트에도착한 데이터

…..

…..

…..…..

서버 클라이언트시퀀스번호 + 데이터

ACK 번호

시퀀스번호 + 데이터

ACK 번호

......

송・수신 동작

시퀀스번호초기값

ACK 번호 접속 동작

ACK 번호

시퀀스번호초기값

: 클라이언트에서 서버에보내는 데이터에 관한 것

: 서버에서 클라이언트에보내는 데이터에 관한 것

ACK번호의대기시간?

대기시간은너무짧지도, 길지도않은적절한(?) 값이어야한다.

TCP는대기시간을동적으로변경.

ACK 번호가돌아오는시간을기준으로대기시간을판단한다.

ACK번호가늦게오면마냥기다려야돼요??

윈도우제어방식에따라효율적으로 ACK 번호를관리한다.

➥한개의패킷을보낸후 ACK 번호를기다리지않고차례대로

연속해서복수의패킷을보내는방법

(a) 핑퐁 방식 (b) 윈도우 제어 방식

서버

클라이언트

ACK 번호를기다리는시간이 낭비됨

서버

클라이언트

ACK 번호를기다리는 사이다음 송신을 하므로낭비가 없음

시간의경과

시간의경과

능력의한계;;를느낄때!

1. 수신측 TCP는패킷을수신하면수신용버퍼메모리에일시보관.

2. 수신측에서 ACK 번호를계산하여조각데이터를복원후애플리케이션에전달.

3. 처리가끝나지않았을때도착한데이터는버퍼에일시보관.

if (애플리케이션에건네주는속도 <데이터도착속도) {

응 ??

}

수신측

송신측

4380 2920 1460 0 1460 02920

빈 영역이 0이 되면송신 중지

보낸 데이터만큼빈 영역에서 뺌

수신용 메모리의빈 영역

데이터를 2,920바이트만큼 추출 수신측

프로그램

수신용 메모리 영역(4,380바이트)

알려줌 다시알려줌

TCP vs UDP

이후의소켓말소, IP와이더넷의패킷송・수신에대한설명은생략~ ^^

UDP

TCP

중개외엔아무것도안해

아직도착안했어다시한번보내줘

데이터를확실히송・수신송・수신속도를조절

Fig1. http://goo.gl/9Eeid0

UDP : User Diagram ProtocolDNS 서버에대한조회등에서짧은제어용데이터를송・수신할경우음성이나동영상데이터를수신할경우

TCP : Transmission Control Protocol브라우저나메일등의일반적인애플리케이션이데이터를송・수신할경우

이제 TCP, 믿을수있겠죠?

[Reference]

[1] “성공과실패를결정하는 1%의네트워크원리”, Tsutomu Tone, 성안당.

[2] “윤성우의열혈 TCP/IP 소켓프로그래밍”, 윤성우, 오렌지미디어.

[3] “뇌를자극하는 TCP/IP 소켓프로그래밍”, 윤상배, 한빛미디어.

[4] http://itpro.nikkeibp.co.jp/article/lecture/20070305/263897/