코딩일지(2024-05-26)

컴퓨터망 24장쪽을 복습했다.

이제 곧 있으면 기말고사이다. 홧팅~

UDP에 대해서

TCP에서는 체크섬이 필수이나 여기서는 그렇지 않음.

UDP 특징>

1. Process-to-Process Communication
2. Provided by socket addresses (IP Addresses + Port numbers)
3. 무선서비스
4. 에러제어없음
5. 혼잡제어없음
6. 캡슐화/역캡슐화

UDP 장점> 1.무선서비스 2.에러제어 없음 3.혼잡제어 없음

• 짧은 요청/응답에 유용함
• 손실되거나 충돌한 패킷을 받아들임
• 혼잡할때 에러가 적다.

UDP 활용>

• DNS에 사용됨

• SMTP에서는 사용못함

• 인터넷에서 대용량의 텍스트파일을 받아올떄 씀

• 스카이프 같은 실시간 상호작용하는 애플리케이션에 적합

• 그 외 활용

1.간단한 요청-응답 통신, 내부 흐름 및 오류 제어 매커니즘, 실시간 애플리케이션, 멀티캐스팅 등에 적합

2.SNMP,RIP에 적합, UDP는 TFTP에서 흐름 및 오류제어를 처리함.

3.실시간 애플리케이션에서 지연을 허용하며, 멀티캐스팅에 사용됨.

TCP에 대해서

TCP: Transmission Control Protocol(전송 제어 프로토콜)

TCP 원리>

• TCP는 신뢰성을 위해 GBN과 SR프로토콜의 장점을 결합함(이때를 위해 지금까지 GBN과 SR을 배운거다ㅇㅇ)
• GBN에서는 여러 패킷을 한번에 전송하고, 누적 ACK번호를 사용함
• SR에서는 실제로 손실된 패킷만을 재전송하여, 전송효율이 높음

TCP 특징>

1.Process-to-Process Communication: 포트넘버에 의해 프로세스와 프로세스가 일대일 대응

2.Stream Delivery Service: 바이트의 연속적인 흐름으로 데이터 전송

3.Full-Duplex Communication

4.Multiplexing and Demultiplexing: 다대일로 보내고! 일대다로 받고!

5.Connection-oriented Service

6.Reliable Service

2.Stream Delivery Service라는 것을 활용한 예시문제가 있더라,

• TCP 연결이 5,000 바이트의 파일을 전송한다고 가정합니다.

• 첫 번째 바이트의 시퀀스 번호는 10,001입니다.

• 각 세그먼트가 1,000 바이트를 전송할 때, 각 세그먼트의 시퀀스 번호 범위는 어떻게 될까요?

해설하자면, 조건이 1000바이트씩의 전송이라고 했으니, 5번 왔다갔다 해야 하는디, 위에 보면 시퀀스 넘버가 만일이고, 이를 포함해서 만일부터 만천까지!

그 다음, 만천일부터 만이천까지! 그 다음, 만이천일부터 만삼천까지! 그 다음, 만삼천일부터 만사천까지! …이렇게 쭉 이어진다.

따라서 정단은 위 사진의 파란색 부분(Range)이다.

TCP 세그먼트>

최소 20바이트의 헤더와 그 0바이트 이상의 데이터로 이루어져 있으며, 최대 65,535바이트까지 꽉꽉 채워서 보낼 수 있다.

1. 소스 포트 주소(16비트)
2. 목적지 포트 주소(16비트)
3. 시퀀스 넘버(32비트)
4. ack 넘버(32비트)
5. 헤더길이(4비트)
6. 리저브드(6비트)
7. 컨트롤(6비트)
8. 윈도우 사이즈(16비트)
9. 어전트 포인터(16비트)
10. 체크섭(16비트)

위 구성요소가 거의 전부인데, 위 키워드를 외웠으면, 아래 상세로 넘어가자!

---

3.시퀀스 넘버(32비트)

싱크 깃발이 1이면? 시퀀스 넘버가 랜덤한 숫자라는 뜻,

싱크 깃발이 0이면? 특정 세그먼트의 시퀀스 넘버라는 뜻,

4.ack넘버(32비트)

수신자가 받을 바이트 단위의 숫자

5.헤더길이(4비트)

4바이트 단위의 워드 수, 뭔말이냐면 여기에 1001,즉 9가 들어가면 헤더길이가 9워드, 36바이트라는 뜻이다.

내가 알기론 20바이트가 최소 마지노선이니까, 5워드부터가 시작이고, 60바이트가 최대마지노선이니까, 15워드가 끝일 것이다.

7.컨트롤(6비트)

• 플로우 컨트롤
• 연결 셋업, 종료, 중지
• 데이터 전송 모드

여기에는 총 6개의 구성요소가 있는데, URG, ACK, PSH, RST, SYN, FIN, 이렇게 구성되어 있고, 각각 1비트로 되어있다.

8.윈도우사이즈(16비트)

윈도우의 최대사이즈는 65,525바이트이다.

수신자가 송신자의 윈도우 사이즈를 정한다.

9.어전트 포인터(16비트)

세그먼트가 어전트 데이터를 포함하고 있을때 사용된다.

10.체크섬(이게 젤 중요할듯?)

체크섬은 UDP에서는 선택사항이지만, TCP에서는 무조건 사용해야 된다.(UDP가 17번 포트, TCP가 6번 포트)

계산방식->UDP에서와 동일하다.(수도헤더 + TCP 헤더 + Data)

3단계 핸드셰이크>

요약하자면,

1. 클라이언트가 액티브 오픈을 수행

2. 서버가 패시브 오픈을 수행
3. 서바가 클라이언트의 ack응답이 올때까지 대기 -> 오면 바로 연결!

“송신자가 수신자의 윈도우사이즈를 정하고, 수신자가 송신자의 윈도우사이즈를 정한다.”

syn flooding attack(동기적 홍수 공격)

해커가 무수히 많은 싱크 세그먼트를 보낸다고 가정했을때 이에 대해 응답을 보내는 데 있어 오류가 발생할 수 있다.(범람문제)

요약하자면, 공격자가 대량의 syn 패킷을 서버에 보내 -> 서버의 자원을 고갈시킴 -> 정상적인 사용자가 서버에 접속하지 못하게 막아

데이터 전송: 피기백(PiggyBack)>

클라이언트 애플리케이션 측에서 요청신호를 두번 보냈다. 가령 처음에는 seq:8000,ack:15001에다가 ack와 ps(푸시)를 담아서 보냈고, 이후 1000을 더해서 seq:9000,ack:15001(이전과 동일)ack와 푸리를 담고 개별적으로 데이터를 따로 담아서 보냈다.

그러면 서버측에서 15001이니까, seq:15001,ack:10001에다가 rwnd:3000을 실어서 보낸다. 또한 데이터를 보내는 것은 기본값이고 말이다.

이를 받고 나서 프로세스(응용계층)까지 전달이 되고 여기서 다시 송신 요청을 보내면, seq:10001,ack:17001에다가 a,rwnd:10000을 담아서 보내게 된다.

세줄요약

1. 송신측은 실시간 전송을 위해 푸시작업을 요청
2. TCP는 푸시비트가 설정된 세그먼트를 즉시 생성하고 전송
3. 수신측 TCP는 세그먼트를 즉시 애플리케이션에 전달하여 추가 데이터를 기다리지 X

---

종료위상>

1. 첫번쨰 종료 위상: FIN
2. 두번째 종료 위상: FIN+ACK
3. 세번째 종료 위상: ACK

처음에 seq:x,ack:y에다가 ack/fin을 싣고 송신측이 보낸다. 그러면 수신측 프로세스가 passive close를 보내고 이를 받은 전송계층이 seq:y,ack:x+1에다가 ACK+FIN을 보내게 된다. 이를 답장으로 받은 송신측은 seq:x+1, ack:y+1,에다가 a를 실어서 보내게 된다.

한가지 고찰이라고 하면, TCP연결은 안전하게 종료하는 것을 보장하기 위해 이런짓까지 하는구나라는 것을 알게 되었다.

요약하면 이런거 같다. 클라이언트: 나 끌낼래!, -> 수신측: 어 그래 끝내!, -> 송신측: ok! 허락 메세지 잘 받았어!

Half-close>

하프-클로스 상태는 클라이언트와 서버간의 연결을 종료하는 과정에서 한쪽이 먼저 연결을 종료하고, 다른쪽은 데이터를 전송할 수 있는 상태이다.

여기서 주목할 부분은 x,y, 그리고 전송계층인것 같다.

송신측에서 액티브-클로스 신호를 보내면, 종료 프로세스로 진입하게 된다. 송신측 전송계층에서 seq:x,ack:y,af를 보냈더니, 바로 seq:y-1, seq:x+1, a를 보낸다.

그리고 이를 통해 서버는 클라이언트에 연결을 닫도록 허락해준다. 이후 client측에서 서버로 계속 ack를 보내는 반면, 서버는 클라이언트 측으로 data 세그먼트를 지속적으로 보네고 되더라.

그리고 수신측에서 프로세스로부터 패시브-클로스 신호를 받게 되면, seq:z(전혀 다른 값),ack:x+1,af를 보내게 된다.

그러면 이에 응답하듯이 클라이언트 측에서 seq:x+1ack:y+1,a를 보내게 된다.

이를 통해 한가지 고찰할 수 있었던 부분이, 하프-클로즈 상태에서는 클라이언트가 먼저 연결을 닫더라도(active close), 서버는 데이터를 문제없이 계속 보낼 수 있다는 것이다.(물론 최종적으로는 양쪽 모두 연결을 종료하겠지만 말이다. 웅웅)

전송계층 다이어그램(Over Time line)>

여기서 중요한건 전송계층이다. 일단 거의 동시에 송신측에서는 엑티브 오픈을, 수신측에서는 패시브 오픈을 했다고 가정한다.

이때 송신측 전송계층에서는 syn을 보내고, syn-sent 모드로 들어가고, 수신측 전송계층에서는 Listen모드로 들어간다. 그리고 첫번째 syn을 받았다고 하자.

그러면 그 즉시 syn+ack를 보내고, 이번에는 syn-rcvd모드로 들어간다. 그리고 이 syn+ack를 받은 송신측에서는 ack신혼를 보내고, 그 즉시 established 모드로 들어간다. 그리고 서로간에 데이터 전달이 이루어진다. 이때 이크에크!(data! ack! data! ack!), 이렇게 주고받기를 시전한다. 그리고 마지막 데이터의 전송이 이루어지게 되면, FIN신호를 보내고, 즉시 fin-wait-1 모드로 들어간다. 그리고 이 fin신호를 받은 수신측 전송계층은 ack를 보내고, close-wait모드로 들어간다.

이 ack를 받은 송신측은 fin-ack-2모드로 들어가고, 이때부터 송신측은 ack를, 수신측은 data를 전송하게 된다. 그리고 이게 끝나면 서버측 프로세스에서 패시브-클로즈 신호를 보내고, 이를 받은 수신측 전송계층에서 fin신호를 보내고 last-ack 모드로 들어가는데, 송신측에서 이걸 받으면 ack를 보내고 time-wait모드로 전환되었다가, 타이머가 끝나면 클로즈 모드로 들어간다. ack를 받은 수신측도 다시 클로즈 모드로 들어가게 된다.

Send Window in TCP>

요약하자면, 송신 윈도우는 수신자가 애드버타이징(광고)한 윈도우 크기에 따라 변하는데, 송신 윈도우 내의 바이트만 전송할 수 있고, 이때 확인되지 않은 바이트는 “Outstanding bytes”로 남아있겠지ㅇㅇ.

새로운 엑크를 받으면 윈도우의 왼쪽 경계가 오른쪽으로 이동하여 더 많은 바이트를 전송할 수 있게 된다.

수신자가 광고하는 윈도우 크기가 줄어들면 송신 윈도우의 오른쪽 경계가 왼쪽으로 이동하여 전송할 수 있는 바이트 수가 줄어들게 된다.

예를 들어 보자. 내가 수신자에게 첫바이트의 데이터를 보내려고 해. 수신자는 송신자의 윈도우 사이즈를 공지할 수 있다고 했듯이, 수신자가 송신자에게 윈도우 사이즈를 300바이트로 애드버타이징했다고 치자. 일단 예시니까 시작바이트고 1번 바이트부터 시작한다고 치자.

그러면 이때 데이터 전송을 시도해보자.

송신 윈도우는 1번부터 300바이트까지를 송신윈도우의 크기로 볼 수 있다.

이때 확인되지 않은 바이트는 앞에 있는 1~100바이트이고, 101~300바이트까지는 전송할 수 이있는 바이트로 취급할 수 있겠다. 그리고 아직 수신자로부터 ack신호를 받지 않았다고 치자.

이후 수신자가 1~100바이트를 확인하고 ack를 송신자에게 보낸다. 송신자는 1~100까지의 바이트를 안정적으로 받았다는 답장을 회신하고 나서, 101번부터 확인되지 않았음을 인지, 그래서 전송할 수 있는 바이트인, 101~300바이트까지 확인되지 않은 바이트로 간주하고, 전송할 수 있는 바이트를 그 다음 301번부터 400번 바이트까지로 두었다.

tcp와 sr에서의 윈도우의 차이>

tcp-> 윈도우 크기를 바이트 수로 측정

sr->윈도우 크기를 패킷 수로 측정

예를 들어, tcp윈도우 크기가 300이라면, 이는 300바이트의 데이터를 보낼 수 있다는 뜻, 반면 SR 윈도우의 크기가 10이라면, 이는 10패킷을 보낼 수 있다는 뜻이다.

tcp-> 타이머 하나만 사용

sr ->여러개의 타이머를 사용

예를 들어, tcp에서는 하나의 타이머를 사용하여 전송된 모든 데이터에 대해 동작하며 이때 타임아웃이 발생하면 모두 재전송 트리거를 하게 된다. 반면, sr에서는 각 패킷마다 개별 타이머를 설정할 수있어, 특정패킷에 대해 개별적으로 재전송을 보내게 할 수 있다.

Receive Window in TCP>

초기에 받은 윈도우의 크기를 100바이트라고 가정해보자. 수신자는 200번 바이트부터 300번 바이트까지 데이터를 수신할 준비가 되어있다.

송신자-> 201번부터 260번 바이트까지 데이터를 보냈고, 수신자가 이를 확인할 상태(ACK)