TCP/IP Protocol Stack
Application은 TCP계열과 UDP 계열의 서비스가 있습니다. DNS는 tcp, udp 둘 다 되는데 보통 udp로 돌아갑니다.
*3계층 Network Layer에 IPv4, IP, ARP, RARP, ICMP로 수정
*TCP는 데이터 전송 전에 3-way-handshaking 작업이 진행이 되어야함, 데이터 전송을 끝낼 때 4 -way-handshaking 작업이 진행이 되어야함.
Paylaod와 Encapsulation
data에 http 데이터가 들어와 있다고 가정해 봅시다.
7,6,5 계층에서 4계층으로 내려옵니다. (payload) payload와 함께 캡슐화 작업이 진행됩니다. http는 tcp계열 서비스이기 때문에 4계층에 TCP 헤더가 붙습니다.
4계층에서 3계층으로 내려옵니다. (paylaod) 그리고 IP는 필수 프로토콜입니다. 때문에 3층에서 IP 헤더가 붙습니다.
3계층에서 2계층으로 내려옵니다.(payload) 어떤 랜을 사용하느냐에 따라 2계층 헤더가 붙는데 우리는 이더넷을 사용해서 Ethernet 헤더가 붙습니다.
*payload는 상위에서 하위 계층으로 내려오는 작업
*캡슐화는 payload가 진행될 때 제어정보가 붙는 작업
TCP Header(4계층)
Data는 있을 수도 있고 없을 수도 있습니다. WireShark에서도 첫 번째 값에 데이터는 안 들어가 있습니다.
Source port address, Destination port address ... Checksum, Urgent pointer 까지 20바이트, options까지 40바이트, 최대 60바이트로 구성될 수 있습니다. 아래서 해당 필드들을 볼 수 있습니다.
TCP 헤더는 20바이트에서 최대 60바이트 까지 늘어날 수 있습니다. TCP 헤더는 가변길이입니다. 그래서 HLEN(header length)이 명시되어 있어야 합니다. HLEN부터... syn, fin까지가 16비트인데, TCP에서는 Flag가 굉장히 중요한 역할을 합니다. 현재 지금 어떤 작업을 하고 있는지를 나타냅니다.
syn에 1이라고 쓰여있으면 데이터 전송 전에 하는 일, 즉 데이터가 없다.
fin에 1이라고 쓰여있으면 finish. 전송이 끝나고 진행되는 일, 즉 데이터가 없다.
syn, fin이 0이면 데이터 전송 중에 tcp가 무언가를 하고 있구나라고 알 수 있다.
- 데이터 전송전(syn==1) : 3way handshake (가상회선 설정)
*서버 up, 서비스 up
*세션 수립(채널 수립)
- 데이터 전송 중
*데이터 전송유무 확인
- 데이터 전송 후(fin==1)
fin은 절차를 지켜서 종료를 하는 것이고, rst는 비정상 종료를 하는 것입니다.
urg=1인 경우, SN이 아닌 Urgent Pointer를 먼저 보고 결정하라는 것입니다. 시퀀스보다 urgent 값을 우선합니다. 시퀀스보다 긴급하게 보내야하는 경우 사용합니다. 우선처리해야하는 데이터에 사용합니다.
psh는 payload 된 데이터가 mss보다 작을 때 마크됩니다.
TCP 연결 관리
1) 3 way handshaking 과정
2) TCP 데이터 전송 과정
3) TCP 연결 종료 과정
TCP 연결 설정(3 way handshaking)
데이터 전송 전에 3 way handshaking 과정을 통해 클라이언트와 서버 사이의 세션을 수립하는 작업을 합니다.
listen 열려 있는 상태, syn를 줘서 ack가 왔다면 established가 됩니다. established는 가상회선이 설립되었다는 의미입니다.
예) SYN : 80번 서비스 열어놨나요? ACK : 네 열려있습니다.
예) SYN : 강사님 수업준비되셨나요? ACK + SYN : 네, 되었습니다. 학생들도 준비하셨나요? ACK : 네
3단계를 진행하면 virtual line이 두 개가 설립됩니다.
[3 way handshake]
1번 라인에서 128번(클라이언트)이 104번(서버)에게 80번 포트 열려있니?라고 물어봅니다. 이때 송신지 포트는 1606이고, 수신지 포트는 80입니다.
2번 라인에서 104번이 128번에서 응 열려있어, 너 내가 데이터 보내면 받을 준비되어 있니? 1606 포트 열려있니?라고 답하고 물어봅니다.
3번 라인에서 128번이 열려있음을 응답합니다.
[cmd창]
대표적인 3계층 명령어 ipconfig
대표적인 4계층 명령어 netstat -an; 네트워크 상태를 확인하는 코드로, a는 모두 보겠다, n은 숫자로 보겠다는 의미
전송하려고 하는 데이터의 번호를 나타내는 것이 sequence number입니다. 3way handshake은 seqence number에 데이터 번호가 없고, 그냥 초기값을 붙여놓습니다. 왜냐하면 3way는 데이터를 전송하기 전이기 때문입니다.
AN(acknowledgement number) = SN(sequence number) + DL(data length)
[문제] http_google을 보고 작성
1. SYN=1 / 2. ACK=0 / 3. AN=0 / 4. ACK=1 / 5. AN=768
6. SYN=1 / 7. SYN=0 / 8. SN=768 / 9. ACK=1 / 10. AN=374
=> AN이 다음의 SN으로 사용
TCP 데이터 전송 과정
1) 정상적인 트래픽 전송과정
http 데이터를 전송했을 때 SN=5000
'데이터 잘 받았다, 두 번째 데이터 보내도 된다'라고 AN으로 답해주는데 그것을 TCP가 합니다.
이어서 SN=5500 전송, 데이터 받음 AN=6100
데이터를 잘 받았다는 답이 와야 다음 데이터를 보낼 수 있습니다.
2) 비정상적인 트래픽 전송과정(1)
SN=5000을 보냈는데 AN=5200이 왔습니다. 원래는 AN=5500이 와야 합니다. 이건 300바이트가 loss 되었음을 의미합니다.
그럼 다시 전송합니다. SN=5000을 보내는데 AN=5400이 왔습니다. 이건 100바이트 loss 되었음을 의미합니다.
다시 전송하니 성공 AN=5000으로 잘 받았습니다. 그래서 이어서 600바이트짜리를 전송합니다.
상대방이 보내주는 AN으로 데이터가 정상적으로 전송되었는데 확인합니다.
sequence number는 데이터 전송 전에 알 수 있습니다. sequnce number와 AN를 비교했을 때 다르면 전송이 잘못된 것을 알 수 있습니다.
3) 비정상적인 트래픽 전송과정(2)
데이터를 전송했는데 AN이 오다가 없어질 수도 있습니다.
그럼 재전송해야 하는데, 3 way handshake에서 rtt 시간을 기록해 놨다가 시간 안에 오지 않으면 재전송하는 것입니다. 이런 방식으로 TCP에서 신뢰성을 보장합니다.
트래픽 흐름제어
Window Size 도 3way handshake에서 결정됩니다.
수신자가 Window Size=3000라고 하면 한 번에 3000을 받을 수 있다는 의미입니다.
(오른쪽부터 왼쪽순, 파란, 초록, 주황 순) 송신자는 1400 사이즈 2개 동시에 보내게 됩니다.
수신자는 AN=7800으로 응답합니다. 그리고 Window Size를 1000으로 보냅니다. 이제 저장공간이 부족하니 1000만 보내라는 의미입니다.
그럼 송신자는 1000에 맞는 데이터를 보내게 됩니다.
수신자 1500에 맞는 데이터를 보내라고 요청하니 송신자가 1400짜리 데이터를 전송하였습니다.
AN=3000으로 응답하였고, Window Size=5000을 보냅니다.
송신자는 1400 * 3개를 보냈는데, 그중 5800이 실패하였습니다.
수신자가 5800이 잘못됨을 알려주면, 송신자는 그 데이터를 다시 보냅니다.
송신자는 AN으로 데이터가 잘 전송됨을 알 수 있습니다. 수신자는 SN로 다음 데이터를 예상합니다.
Window size = 0의 의미는 '내가 데이터를 저장할 공간이 없다. 너가 보내면 다 드롭된다. 그니까 보내지 마라'라는 뜻입니다.
TCP 연결 종료 과정(4 way handshake)
1 client가 server한테 우리 이제 연결 끊자 할 때 finish를 보냅니다.
2 close_wait는 일단 finish에 대한 ACK(응답)한 상태입니다. 그리고 클라이언트에게 할당되어있던 프로세서를 종료하는 작업을 합니다.
5 close_wait에서 last_ack로 안 넘어가면 정상적으로 프로세스가 종료되고 있지 않음을 의미합니다. 이때 애플리케이션 상태를 확인해야 합니다. 정상적으로 넘어가면 server는 client에게 정말 끝낼까요?라고 finish를 보냅니다.
7 client는 끝내자고 답합니다. 그러면 server가 먼저 closed가 됩니다.
8 마지막에 client가 closed가 됩니다.
왜 서버를 끊고 클라이언트가 끊을까요??
클라이언트가 대답하자마자 클라이언트에서 서버로 가는 virtual line이 끊깁니다. 그러나 대답이 중간에 세션이 끊겨 서버가 ACK를 못 받았다면?! 그럼 서버는 계속해서 끊을까요 끊을까요 물어봅니다. 그래서 클라이언트가 먼저 끊기면 서버는 응답을 받지 못하고 오버헤드에 걸려버립니다.
클라이언트가 time wait 상태로 있는 동안 서버는 close 되고 그다음에 클라이언트도 close가 됩니다. 마지막 안전을 위해 time wait이 있는 것입니다.
UDP Header(4계층)
- Data 전송을 위하여 사전에 필요한 Process가 없음
- Best-Effort Delivery
- 신뢰성 보장 못함.
TCP는 가변길이를 쓰지만 UDP는 고정길이를 씁니다.
source prot number부터 checksum까지 8바이트입니다.
UDP Length는 헤더와 데이터의 총합을 담고 있습니다.(Total Length)
Checksum은 오류검출코드입니다.
udp 필드에는 재전송 관련 필드가 없습니다. 송신자 쪽에서는 오류검출 코드를 보내고, 수신자 쪽에서는 오류검출 코드를 통해 확인을 하는데, checksum이 있어도 재전송 기능이 없습니다. 사실상 무용지물이라고 할 수 있습니다. 문제가 있어도 재전송이 없기 때문입니다. 그래서 신뢰성을 보장하지 못합니다.
현업에서 문제가 있을 경우 UDP 자체에서는 못하니 application에서 즉 7계층에서 대책을 세웁니다. (선택적 작업)
아래 그림에서 필드값들을 확인할 수 있습니다.
UDP 전체 길이가 39이고 페이로드가 31이므로 udp 헤더는 8입니다.
TCP와 UDP
TCP 방식
- Stream-Oriented Transport Protocol (스트림기반;조각조각)
- 상위계층에서 payload 된 데이터를 단편화
- 신뢰성 있다, 느리다
UDP 방식
- Message-Oriented Transport Protocol (메세지기반;덩어리)
- 상위계층에서 payload 된 데이터를 단편화하지 않음
- 간단하다, 빠르다, 네트워크 부하가 적다, 신뢰성을 보장하지 않는다.
UDP 기반 애플리케이션 데이터 전송
UDP는 단편화 성향이 없기 때문에 7계층에서 4계층으로 그대로 Payload 됩니다.
그다음 4계층에서 3계층으로 내려갑니다. (3계층)IP에서 단편화를 진행합니다.
TCP 기반 애플리케이션 데이터 전송
TCP는 단편화기능을 가지고 있습니다. MSS 사이즈를 5000 byte인데 들어온 데이터가 4000입니다. 그렇기 때문에 단편화를 하지 않고 7계층에서 4계층으로 그대로 Payload 됩니다. TCP는 MSS에 따라 단편화를 할수도 있고 안할수도 있습니다.
이번에는 MSS 사이즈가 2000 byte인 경우입니다. 7계층에서 4계층으로 내려올 때 단편화를 할 수밖에 없습니다. 2000 byte 씩 분할합니다. 데이터가 분할이 되면 분할된 데이터마다 sequence number를 부착합니다. 앞에 있는 SN=1100이면 두 번째 SN은 SN+DN(데이터길이)를 해서 3100이 됩니다.
그다음 4계층에서 3계층으로 올 때는 MSS가 1500으로 되어 있습니다. 그럼 또다시 단편화를 합니다.
*여기서 MSS는 변할 수 있는 가변입니다. 반면 MTU는 고정입니다.
MSS가 1400인 경우 7->4계층으로 내려올 때 단편화가 진행이 되고 4->3계층으로 내려올 때는 MSS를 넘어가지 않으므로 단편화 작업 없이 그대로 내려옵니다.
[!!중요!!]
* MSS는 4계층, MTU는 3계층
* 최적의 mss는 3계층에서 단편화를 하지 않게 하기 위한 세그먼트의 크기!!
* 3계층에서 단편화를 하게 되면, 재조립하는데 시간이 많이 걸림
*tcp header가 25바이트, ip header가 25바이트라면 최적의 mss는 얼마인가? [아래 그림과 같이 보기~mss부분]
=> MTU는 1500, ip는 25, tcp는 25! 즉, 1500-25-25 = 1450
=> 최적의 mss 사이즈는 1450!!
=> 이렇게 되면 3계층에서 단편화를 하지 않아도 됨,
IP Header(3계층)
Data는 무조건 있어야 합니다. TCP는 생략 가능하지만 IP는 필수입니다. 쓰레기 값이라도 달고 나옵니다.
데이터가 영상일 수도 있고 일반 데이터일 수도 있습니다. 안전하게, 비용이 적게, 빠르게 등 전송하려는 데이터의 서비스 품질을 명시해 주는 부분이 Service Type이다.
아래 그림에서 필드값들을 확인할 수 있습니다.
MTU(Maximum Transfer Unit)
네트워크 기기가 전송할 수 있는 최대 전송단위를 의미합니다. 네트워크 환경에 따라 각각의 크기는 다르고, 우리는 이더넷을 사용하기 때문에 MTU는 1500입니다.
단편화(Fragmentation)
- 송신자는 단편화를 하고 수신자는 그것을 재조립한다.
- MTU가 큰 네트워크에서 MTU가 작은 네트워크로 데이터그램이 전송될 경우 데이터그램은 나누어져서 보내져야 합니다.
- 재조립으로 인해 발생하는 비효율성 때문에 전송 중에는 재조립이 안됩니다.
4000에서 1500/1500/1000으로 조각난 것입니다. A 뒤에 있는 숫자는 A의 1번째 조각, A의 2번째 조각, A의 3번째 조각이라는 의미입니다. 마지막 숫자는 1일 경우 내 뒤에 조각 있음을, 0일 경우 내 뒤에 조각 없음을 의미합니다.
TCP의 sequence number는 IP header의 identification과 동일한 역할을 합니다. 전송하려는 데이터의 번호를 의미합니다.
연속해서 데이터가 나오면서 아이디가 같으면 문제가 있을 수 있습니다.(초록색, 14567) 그러나 단편화일수도 있습니다.
14567이 3개로 단편화가 된 것인데, 1420 1420 1220으로 분할되었습니다. fragment offset은 상대번지를 나타냅니다. (초록색의 빨간 글씨) 플래그는 0과 1로 뒤에 조각이 있는지 없는지 유무를 나타냅니다.
단편화 확인하는 필드는 id, flags, fragmentation offset입니다.
3장의 사진을 비교해 보면 ID 값은 같습니다. Flag의 경우 1,2번째만 1로 되어있고, 3번째는 0으로 되어있습니다.
MSS(Maximum Segment Size)
MSS는 TCP 상에서 전송할 수 있는 사용자 데이터의 최대 크기를 의미합니다.
MTU는 IP header + IP data(TCP header+Payload) = 1500을 의미합니다.
실제 전송하는 데이터 길이는 1500 + 18 = 1518
계층마다 데이터를 부르는 이름(단위)이 다른데 이것을 PDU(protocol data unit)라고 합니다.
7계층 messgae
4계층 Segment --> datastream
3계층 Packet(ip) --> datagram
2계층 Frame(mac)
1계층 bit
EX 1)
MTU = 1500, Ethernet frame =1518
ip header = 20
tcp header = 20
MSS = 1500-20-20 = 1460
EX 2
ip header = 30
tcp header = 30
MSS = 1500-30-30 = 1440
TTL(Time To Live)
라우터와 라우터 간격을 hop 이라고 합니다. TTL=3인 경우, 로컬 게이트웨이까지는 TTL이 바뀌지 않습니다. 그 이후 다리 하나를 건널 때마다 TTL이 1씩 줄어듭니다.
TTL=3인 경우 홉을 3번 갔는데도 목적지를 못 가는 경우 0이 되는 순간 그냥 버려집니다. 즉, TTL은 목적지까지 가기 위한 최대 홉수를 의미합니다.
TTL이 너무 작으면 목적지에 가기 전에 중간에 패킷이 버려질 수 있고, 너무 크면 목적지를 찾아서 헤매는 루핑현상이 나타날 수 있습니다. 이 TTL 값은 운영체제가 결정합니다.
[cmd 창]
netsh는 로컬 또는 원격 구성의 네트워크 설정을 변경하는 명령어입니다.
MTU와 TTL 값은 운영체제에서 조절할 수 있습니다.
*MTU 설정 변경
C:\> netsh interface ipv4 set subinterface “6" mtu=9000 store=persistent (변경)
C:\> netsh interface ipv4 show global (보여줘)
*TTL 값 변경
C:\> netsh interface ipv4 set global defaultcurhoplimit=64(변경)
C:\>netsh interface ipv4 show global (보여줘)
레지스터 편집기를 사용하는 방법도 있습니다.
Header checksum
checksum은 헤더의 오류를 검증하기 위해 사용합니다. 송신자 쪽에서는 checksum을 제외하고(version필드부터 목적지 IP 필드값까지) 다 더한 값을 checksum에 첨부하여 보냅니다. 수신자 쪽에서도 다 더해보고 checksum과 비교하여 오류가 있는지 없는지 확인합니다.
Ethernet Frame(2계층)
Length PDU는 Type이라고도 합니다.
CRC는 WireShark에서 숨겨놓았습니다. 왜냐하면 추적파일의 경우 오류가 나타났다는 경우가 종종 있기 때문입니다.
[추가] CRC를 나타내는 방법!!
** DIX frame은 호스트에서 생성되는 2계층 데이터이고, IEEE 802.3 frame은 스위치, 라우터와 같은 네트워크 장비에서 생성하는 2계층 장비입니다.
[추가 설명]
1. 172.16.0.122이 4.2.2.1에게 www.espn.com의 ip주소를 요청
2. 4.2.2.1이 ip주소 알려줌
3-5. 3way hand shaking 작업
6. 3way hand shaking이 맺어져서 HTTP 나옴. HTTP 싣고 가는 걸 볼 수 있음.
요청메세지(get) : GET / => index.html 요청한 것임
7. 301이 왔다는 것은 사이트 이전을 의미. 원래 사이트 이름은 www.espn.com, 바뀐 사이트 이름은 http://espn.go.com
9-10. 사이트가 이전했으므로 http://espn.go.com의 ip주소를 요청
11-13. 3way hand shaking 재작업
----------
200 성공
300 방향 재지정(리다이렉트)
400 클라이언트 오류
500 서버 오류