Transport layer

RTT (왕복 시간)

전송 속도 R (초당 전송 가능한 비트 수)

패킷 길이 L (전송해야할 총 비트 수)

• 송신자의 효율이 0.00027로 왕복 시간이 길수록 효율이 낮아짐
• l / r : 몇 초동안 전송해야 이 비트들을 보낼 수 있는지 시간이 나옴

piplined protocols

• 한번 패킷을 보낼 때, 여러 개를 보내서 한번에 여러개의 응답을 받을 수 있게 하는 것
  • go-back N protocols

go-back N protocol

• 윈도우 사이즈로 조절하면서 여러 개의 패킷을 보낼 수 있으나 패킷 유실 발생이나 패킷 오류 발생 시 윈도우 사이즈만큼 바퀴를 돌아야하는 문제가 발생
• sender
  • window size를 보고 그 사이즈만큼 패킷 여러 개 전송
  • 각각의 패킷을 보내고 나서 응답에 대한 timer가 존재
• receiver
  • 여러 개의 패킷이 들어올 때 순서대로 들어온다는 보장이 없음
  • 그래서 처음에 0번 패킷 받고 그 다음으로 1번 패킷을 받아야하는데 2번 패킷 먼저 오면 3번 패킷 버리고 1번 받고 ack 1보내고 2번 기다리는데 아까 2번 버려서 3번 패킷이니까 3번 버리고 이런식으로 패킷이 밀려버림
  • 리시버 측에서 6번이 패킷 유실 확인되면 window size가 4일 때 4개짜리를 한바퀴 더 돌고 가야하는 셈임
    • 0123 1234 2345 3456 4567 5678 6789 6789(6번 패킷이 없어서 ack 못보내니까 나머지 뒤에 있는 패킷을 다 버리기 때문에 한바퀴 더 도는 것임) 78910

selective repeat

• sender
  • 윈도우 사이즈 크기만큼 보낸 패킷 별로 타이머 존재하고 해당 타이머 시간안에 들어온 ack 메시지 패킷은 다시 보내지 않음 (타이머 소멸)
  • 앞서 2, 3번 패킷중 3번 패킷이 먼저 들어오게 된다면 해당 3번 패킷에 대한 타이머는 소멸. 2번 패킷에 대한 타이머는 터짐 → 그럼 재전송을 함
  • 송신측 버퍼에서 ack메세지가 잘 도착한 패킷은 삭제
• receiver
  • 윈도우 사이즈 크기만큼의 버퍼를 만들어 어떤 패킷이 정상적으로 들어왔는지 적어둠

시퀀스 넘버의 크기 문제

• sender에서의 윈도우 사이즈 크기에 맞춰 패킷을 보냈는데 윈도우 사이즈 크기만큼 시퀀스 넘버를 정한 경우 ex) win = 3, seq length = 3
  • 0번 패킷이 다음 패킷에 대한 0번 시퀀스 넘버를 뜻하는데 리시버는 새로운 패킷이라 생각하고 버퍼에 저장해두게 되는 문제 발생
  • 시퀀스 넘버를 키우면 되는 문제이지만 최소한으로 해야함

TCP

• 특징
  • 데이터를 주고받는 소켓은 두 곳 모두 리시버이자 센더의 역할을 할 수 있음
    • 즉 각 프로세스별로 샌더 버퍼, 리시버 버퍼가 존재하는 것
  • 프로세스와 프로세스 간의 통신을 하는데 프로세스에서 여러 포트를 열어 소켓을 생성할 수 있으나 그 중에서도 하나의 포트를 열어서 소켓을 연결해 사용하는 방식임
  • Go-back N과 다르게 seq 넘버는 sender기 리시버한테 보낼때 몇번째를 보내야하는지 기억하는 것이고 ack은 샌더가 리시버한테 어디까지 받았다를 의미하는데 go-back은 ack를 받은 번호를 보내두는데 tcp는 받을 번호를 얘기함 9번까지 받앗으면 10번 보내는거임
  • Timeout : rtt 를 기준으로 사용하려 했으나 네트워크 상황, 세그먼트별로 도착하기까지 돌아다니는 길 등이 천차만별이라 시간차가 큼.. 따라서 sample rtt(각 세그먼트 별로 측정된 시간) 에 estimated rtt에 0.12값의 가중치를 둬서 계산을 해 구한다 (중요하지 않음)
  • 시퀀스 뭉탱이로 보내는거 한 뭉탱이 당 타이머 하나가 됨 go-back 같은 경우에는 윈도우 사이즈 내부 하나에 여러개 타이머 존재하나 tcp에서는 세그먼트 뭉탱이 별로 한개 존재
  • 따라서 뭉탱이 시간 끝날 시 뭉탱이를 다시 보냄
  • cumulation ack : 뭉탱이로 받은 패킷의 마지막 ack만 보내기
• timeout이 터지기 전에 패킷 유실을 확인할 방법?
  • 세그먼트 100개를 순서대로 보넀을 때 10번 유실이면 ack9 다음 ack10 ack10 ack10 달라고 계속 보낼거임 receiver의 버퍼에 10번빼고 나머지는 쌓여있는 상태.
  • fast retransmit : 따라서 ack10 여러 번 날라오면 결국 timer 터지기 전에 패킷 유실을 알아낼 수 있음
    • fast retransmit은 있어도 되고 없어도 되고, timer는 무조건 있어야하는것
      • 3 dup (duplicate)
        • 총 ack 3번 반복, 첫번째 ack는 빼고 3번 반복이라 결국 총 합은 4번 반복임!!!!!!!!!

TCP FLOW CONTROL

• 각 통신 프로세스는 send buf, recv buf를 가짐
  • send buf는 recv buf가 감당할 수 있는 만큼 조절해서 보내야 함
  • recv buf는 받은 것을 application으로 올려줌
  • 따라서 receiver는 header에 recv buffer size를 같이 보내줌
    • receive buffer size: 현재 얼마만큼 자리가 있는지 버퍼 남은 공간 수 알려주기
    • send 측은 reciever가 패킷을 보내지 않으면 알 방법이 없으니, sneder측에서 data 는 비어있는 패킷을 막 보냄 그럼 reciever측에서 해당 패킷에 대한 응답값을 보내니 그때 확인이 가능

3way handshake

• tcp header에 연결하고자 하는 곳에 패킷을 보내는데 나의 seq 번호와 SYN를 1로 설정 ( 패킷 통신일 때는 0을 유지하나 tcp 열고 닫을 때 1로 변경)
• SYN/ACK를 보내고 시퀀스 번호 y 보냄
• ACK를 보냄 (데이터를 포함해서 보냄)

closing TCP Connection

• client측에서 보낼 데이터를 다 보냈다는 의미로 FIN 보냄
• Server측에서 ack받고 서버측에서 데이터 다 받고 정리되면 FIN 보냄
• clinet는 fin을 받았다고 ack를 보내야함
  • ack를 안보내면 server측은 계속해서 fin을 보내게 됨

congestion control, flow control 중 더 상태가 안좋은 곳에 맞춰서 sender는 데이터를 보내야하는 것임

congestion control

• 인터넷 네트워크는 많은 컴퓨터들이 사용중인 공공의 개체임. 각각의 pc들은 데이터를 많이 받기를 원함.
• 네트워크가 계속해서 막히면 데이터를 계속 보내고 그럼 더 막히게 됨
• 따라서 각자 자신을 위해서 데이터 양을 줄여서 보내기로 함

congestion control 해결 방법

1. router가 sender측에 네트워크 상황을 피드백해서 줌 (사용 안함)
2. tcp의 세그먼트를 보냈을 때, ack의 상태를 빨리 피드백이 오는지, 유실되는지를 보면서 네트워크 상태를 알아서 잘 유추하는 것
   1. Slow Start : 네트워크 망은 다같이 쓰는 곳이기 때문에 유추하기 위해서 마구 데이터를 쏟아부으면 안되고 작은 양만 보내서 네트워크 상황을 확인함
      1. 처음은 겸손하게 1개였다가 2개,3 , 4개 이렇게 증가시키면 100000개를 어느새월에 보냄. 그러니까, 기하급수적으로 늘리는 것임 1,2,4,8,16 이런식으로 보냄
      2. 따라서 실제로는 slow하지 않고 빠름
   2. Additive increase : 어느 지점을 지나는 순간 linear하게 보냄 조금씩 늘림 1,2,3 (window size 조절)
   3. multiplicative decrease : 뭔가 혼잡이 생겼을 때, 대폭 줄여야지 그 혼잡을 바로 잡을 수 있음 (절반 가까이)
   4. MSS (Maximum segement size ) : 500 byte
      1. slow start에서 데이터 갯수 늘리는 것으로 window size 한개당 1MSS에 해당하기 때문에, window size는 곧 한번에 마구 보낼 수 있는 세그먼트의 사이즈를 뜻함
   5. 전송 속도 : congestion window 사이즈가 결정함. 대략적인 속도는 congestion window size를 RTT로 나누면 됨

timeout, 3 dup ack 네트워크 상황 차이

• timeout 은 네트워크 매우 혼잡 상태, 3dup은 해당 패킷만 유실 된거기 때문에 빠른 회복으로 threashhold의 절반만 줄이고 linear하게 증가, timeout은 slow start부터 시작
• threashhold는 윈도우 사이즈의 절반으로 지정해둠
  • Threshold의 값을 timeout이 발생한 cwnd의 절반으로 설정

tcp fairness

• 각 pc에 있는 tcp는 congestion avoidance를 피하기 위해 결국 어느 순간에는 1/2로 줄이고를 반복, 모든 pc가 동일 따라서 가운데에 수렴. 그래서 각 tcp를 하나씩만 열었을때는 공평하게 사용하는 상황이 됨
• 하지만 어느 한 컴터에서 tcp하나 더 열면 그때는 그 pc가 두배를 쓰는 거임