[컴퓨터 네트워크] Chapter3) Computer Network : Transport Layer

Chapter3) Computer Network : Transport Layer

complete.

1. Introduction 

• 네트워크 - 전송 - 어플리케이션 
• 서로 다른 호스트(시스템)  상의 프로세스 간 커뮤니케이션 제공
• 논리적 연결 사용 

1.1 전송 계층이 제공하는 서비스 

 

1.1.1 프로세스 간 커뮤니케이션 (Process to process communication)

• 프로세스 : 전송 계층 서비스를 사용하는 실행 중인 프로그램 (객체) 
• 네트워크 계층 - 호스트가 목적지 컴퓨터로 메시지 전달만 가능 
• 전송 계층 - 각 호스트 내부의 프로세스 간 메시지 주고 받기 
• 즉, 네트워크 계층에서는 어떤 호스트로 메시지를 전달할지 결정하고, 전송 계층에서 해당 호스트 내부의 여러 프로세스 중 전달받을 프로세스를 결정하는 것 

1.1.2 addressing: 포트넘버

• 오늘날 운영체제는 멀티유저, 멀티 프로그래밍 환경 제공
• 커뮤니케이션을 할 때 로컬 호스트, 로컬 프로세스, 원격 호스트, 원격 프로세스 정의해야 함
• 로컬 호스트와 원격 호스트는 IP 주소로 정의 
• 각 호스트 내부에는 여러개의 프로세스가 있는데 프로세스들은 포트 넘버로 구분
  • TCP/IP 프로토콜에서 16bit 정수 포트 넘버 0~65,535 중 하나  
• 클라이언트 프로세스는 ephemeral 포트 넘버 사용 (1023 보다 큼)
• 서버 프로세스는 잘 알려진 포트 넘버 사용 : TCP/IP 프로토콜이 유니버셜한 서버 포트 넘버 결정
• IP 주소와 포트 넘버는 데이터의 전달 목적지를 결정하는데 각각의 역할을 함
  • IP 주소 : 여러 호스트 중 목적지 호스트 찾기
  • 포트 넘버 : 특정 호스트 내부에 여러 프로세스 중 특정 프로세스 찾기 

1.1.3 ICANN ranges

• ICANN : Internet Corporation of Assigned Names and Numbers 
• 포트 넘버를 세 범주로 나눔 
  • 0~1023 : well known ports, 잘 알려진 어플리케이션 프로토콜이 사용 예약 
  • 1024~49151 : registered ports, 중복 방지를 위해 등록해서 사용, ICANN이 할당하지 않음
  • 49152~65535 : dynamic ports, 임시 또는 개인 포트 넘버로 제어 또는 등록되지 않음 (클라이언트, 서버 포트넘버) 

1.1.4 소켓 주소 

• 소켓 주소 : IP 주소 + 포트 넘버 
• 인터넷에서 전송계층 서비스를 사용하기 위해 클라이언트와 서버 소켓 주소 필요함 
• 네트워크 계층 패킷 헤더 - IP 주소
• 전송 계층 패킷 헤더 - 포트 넘버
• 클라이언트와 서버 포트 넘버는 같을 수 있지만 권장되지 않음 

1.1.5 excapsulation, decapsulation

• 캡슐화 : 어플리케이션에서 보낼 메시지를 만들어 전송 계층으로 보냄 -> 패킷에 페이로드와 함께 넣고, 헤더와 함께 보냄 
• 디-캡슐화 : 전송 계층에서 헤더와 함께 온 패킷을 받고 메시지만 꺼내 어플리케이션 계층으로 보냄 

1.1.6 multiplexing, demultiplexing

• multiplexing (many to one) : 보내는 곳의 전송 계층에서 수행, 두 개 이상의 시그널을 결합하는 작업 
• demultiplexing (one to many) : 받는 곳의 전송 계층에서 수행, 멀티플렉스 된 적 있는 두 개 이상의 시그널을 분리하는 작업 

1.1.7 흐름제어 Flow control 

• 데이터 전송 비율을 관리하는 것 
• 데이터를 받는 쪽에서 데이터 손실을 막기 위한 제어 
• 받을 수 있는 쪽이 수용 가능한 속도보다 빠르게 또는 느리게 생산하는 경우를 관리 
• pushing : 메시지 생산자는 아이템을 푸시 함, 데이터 생산자의 요청 없이도 데이터를 보내는 것 -> 소비자가 압도될 수 있기 때문에 데이터 손실을 막기 위해 흐름 제어 필요 
• pulling: 데이터 소비자가 데이터를 요구한 후에 생산자가 데이터를 전송함 -> 흐름 제어 필요 없음 
• 흐름 제어 객체 : sender 프로세스와 전송 계층, receiver 프로세스와 전송 계층 

• 주고 흐름 제어 솔루션으로 두개 버퍼를 사용함 : sender, receiver 각각의 전송 계층에 buffer 둠 
  • sender 전송계층의 버퍼 : 어플리케이션 계층에서 보내는 메시지가 가득 차면 full되고, 비어 있으면 메시지 보내도 된다고 알림
  • receiver 전송 계층의 버퍼 : 가득 차면 sending 패킷을 그만하라고 알리고 비게되면 다시 보내라고 알림  

1.1.8 오류 제어 Error Control 

• 인터넷에서 네트워크 계층은 신뢰도 떨어짐 
• 어플리케이션 계층에서 신뢰도가 필요한 경우, 전송 계층에서 오류 제어를 해야 함 
• 신뢰할 수 없는 패킷을 탐지하고 버림
• 손실되거나 버려진 패킷을 추적해서 다시 보냄
• 패킷 중복을 알아차리고 버림
• 버퍼에 패킷 순서가 뒤섞인 경우 에러 제어 
• sequence number 사용
  • 패킷은 sequence number를 가지고 있음 
  • 일정 범위의 연속적인 숫자를 각 패킷들이 가지고 있는데 그 중 숫자 하나가 비면 에러가 발생함을 의미함 
• signal - positive, negative (패킷의 전송 여부 표시)
• acknowledgement (ACK) 사용
  • 시간을 정해두고 ACK가 안오면 에러라고 판단 
  • 그러면 sender는 패킷 다시 보냄 

 

1.1.9 혼잡 제어 Congestion Control 

• congestion : 네트워크의 용량보다 부하가 큰 경우 혼잡 발생
• 라우터와 스위치에 패킷을 가지고 있는 큐가 오버로드될 수 있음 

1.1.10 연결 지향 / 비연결 서비스

• connectionless 서비스 : 보내는 패킷간 연관성 없음, 두 전송 계층간 협업 없음, 흐름 오류 혼잡 제어 없음
• connection-oriented 서비스 : 패킷 간 연관성 있음, 클라이언트와 서버간 논리적 연결 필요, 흐름 오류 혼잡 제어 있음 
• finite state maching (FSM) 

2. 전송 계층 프로토콜 Transport layer protocols 

• TCP/IP의 전송 계층 프로토콜은 여러 프로토콜의 조합 또는 수정된 것을 사용
  • simple, stop and wait, go back n, selective repeat 프로토콜 등 

2.1 Simple 프로토콜

• connectionless 프로토콜
• 흐름 오류 제어 없음
• 보낼 패킷이 있으면 그냥 보내고, 받음 
• no ACK
• receiver를 고려하지 않고 보냄 

2.2 Stop-and-Wait 프로토콜

• 연결 지향 프로토콜
• 흐름 오류 제어 있음
• sender가 하나의 패킷을 보내고 타이머를 시작하고 ACK를 기다림
• 타임아웃 될 때까지 ACK가 안오면 이전 패킷을 다시 보내고
• 타임아웃 전에 받으면 타이머를 멈추고 다음 패킷을 보냄
• checksum : 전송 사전 약속으로 패킷의 정확성 확인 
• ACK가 오지 않아 패킷을 다시 보내는 경우 패킷 중복 발생 가능 
  -> 이를 방지 하기 위해 sequence number를 사용 
  -> missing 패킷 판별 
• sequence number convention : 받는 쪽이 예상하는 다음 패킷의 sequence 넘버를 항상 ACK 넘버가 알림 
  ex) 0번 패킷이 안전하게 도착하면, 받은 쪽은 ACK (0+1)mod2 = 1을 보냄 이는 패킷 1번이 다음 패킷으로 올 것으로 예상한다는 것을 알림 / 1번이 도착하면 받는 쪽은 (1+1)mod1 = 0을 보내고 다음 패킷은 0번이라고 예상하는 것을 알림 
• 채널이 대역폭이 넓고 전송 구간이 길다면 비효율적인 프로토콜 
• ex) 대역폭 : 1Mbps, round trip : 20 ms/bit 
  => bandwidth-delay product (1 x 10^6) x (20 X 10^-3) = 20,000 bits
  => utilization = 1,000/20,000 = 5%   // 보내는 패킷 전체의 bit를 bandwidth-delay product로 나눈 값 
  ==> 여기서 15개의 패킷을 한번에 보낼 수 있게 되면 delay는 여전히 같고, utilization 15,000/20,000 = 75%
• pipelining : 이전 패킷에 대한 피드백이 오기 전에 여러개의 패킷을 연속으로 보내는 것인데 이 프로토콜에서는 사용하지 않음 

2.3 Go-Back-N (GBN) 프로토콜

• sender가 받은 쪽이 보내는 ACK를 기다리는 동안 효율성을 높이기 위해 여러 개를 보내는 파이프라이닝을 사용
• ACK를 받기 전에 여러 개의 패킷을 보내고, 받는 쪽은 오직 하나의 패킷만 버퍼에 넣을 수 있음 
• send window는 여러 패킷 저장, receive 윈도우는 하나의 패킷만 저장 
• seqnece number 2^m
• acknowlodge number = 특정 번호 까지의 패킷을 받았다는 것을 나타냄, 다음에 올 패킷으로 예상되는 넘버를 정의함 
  ex) ackNO = 7, 총 여섯개의 패킷이 왔고, 다음 7번 패킷을 받을 것이라고 예상한다고 알리는 것 
• sender window : 데이터 패킷들의 sequence number 저장 
  • Sf : first outstanding, 보내졌으나 ACK가 오지 않은 sequence number들
  • Sn : next to send, 다음 패킷으로 보내질 sequence number 
  • Ssize : 윈도우 사이즈 (최대 2^m-1) ** 2^m이면 ACK 안받은 패킷이 있음에도 재전송이 안되는 경우 발생 
  • Sn(아직 보내지지 않은 패킷) 보다 작고, Sf(보내졌으나 ACK오지 않은 패킷) 보다 큰 것에 대한 에러 없는 ACK가 오면 send window가 한 칸 이상 옆으로 이동함 

 

• receive window : 정확한 데이터 패킷을 받고 정확한 ACK를 보내야 함 
  • Rn : single 변수, size 1 
  • 다음에 올 패킷의 시퀀스 넘버로 예상되는 것 
  • 정확한 패킷이 오면 윈도우 한칸 이동
  • Rsize = 1
  • ex) Rn = 5 :패킷이 4까지 왔고, 다음 5가 올 것이라고 예상함을 의미함 
• Timer : 오직 하나의 타이머 사용, 패킷을 보낸 후 타이머 설정
• resending packet : 타임아웃되면 모든 실패한 패킷들을 다시 보냄 
  ex) Sn=7 타임 아웃 Sf = 3인 경우 패킷 3, 4, 5, 6이 ACK를 받지 못했음을 의미함 -> 다시 3으로 돌아가 다시 보냄 
• 받는 쪽 프로세스를 간단하게 만들지만 네트워크 프로토콜이 많은 패킷을 손실하는 경우에는 비효율적 

2.4 Selective-Repeat 프로토콜

• GBN 프로토콜을 발전시킨 버전
• 실제로 손실된 패킷들만 resend 
• 파란 블럭 : 보냈지만 ACK가 오지 않은 것
• 회색 블럭 : 순서에 맞지 않게 ACK가 온 것 
• send window 사이즈가 최대 2^(m-1) = receive window size 
  ex) m = 4 인 경우 sequence number = 0~15, 윈도우 최대 크기는 8 (GBN의 경우 15) 
• Timer : outstanding 패킷을 개별적으로 다룸, 주로 하나의 timer 사용
• Acknowlegement : ackNo는 잘 전달된 하나의 패킷의 시퀀스 넘버를 정의 (=에러 없이 잘 전달된 패킷의 시퀀스 넘버)
• example

패킷 0 보냄

 

2.5 example : GBN vs. SR.

• 6개의 패킷을 보내는 경우 를 가정 (0,1,2,3,4,5) 
• sender는 ackNo=3을 받음
  • GBN : 0,1,2 패킷을 정상적으로 받았고, 이제 receiver가 3번 패킷을 기다린다는 것을 의미
  • SR : 3번 패킷이 정상적으로 도달했고, 다른 패킷에 대한 것은 ACK가 알려주지 않음 

2.6 Bidirectional Protocols : Piggybacking

• 위 4가지 프로토콜은 단방향 프로토콜
• piggybacking은 양방향 프로토콜로 효율성이 높음 
• 클라이언트와 서버 양 쪽 모두 sender, receiver가 될 수 있음 
• 패킷 하나가 seqNo와 AckNo를 둘 다 가지고 있음 

3. Internet Transport Layer protocols

• 네트워크= 소통할 수 있게 하는 디바이스들의 연결 조합
• 컴퓨터, 데스크탑, 핸드폰 등 모든 호스트들간 연결을 위해 라우터, 스위치, 모뎀 등을 이용해 데이터를 형태를 바꾸고 소통함 
• 인터넷 전송 계층 프로토콜 대표 : UDP, TCP

3.1 UDP (User Datagram Protocol)

• connectionless
• unreliable 
• simple, 적은 오버헤드 
• 프로세스-프로세스 소통 제공 
• 안정성은 별로 중요하지 않고, 작은 메시지를 보내는 경우 적합 
• UDP 패킷
  • 각 2byte * 4 = 8 byte header 
  • source port  : sending port (사용되지 않는 경우 0)
  • destination port : receiver port (필수)
  • total length : 전체 데이터그램 (헤더, 데이터) 의 바이트 길이를 16-bit으로 표현
  • checksum : 헤더와 데이터의 에러를 체크하는데 사용하는 16bit 필드 
  • ex) CB84/000D/001C/001C = source/destination/total/checksum  = 52100/13 = daytime port number/ 28 bytes - data 길이 20bytes/ 
  • destination port로 client (받는쪽) 프로세스가 무엇인지 알 수 있고, 전체 길이에서 8바이트 (헤더길이)를 뺀 값이 데이터의 길이

• UDP 서비스 
  • 프로세스 간 커뮤니케이션 : IP 주소와 포트 넘버의 조합, 소켓 주소를 사용해서 프로세스간 소통 제공
  • 비연결 서비스 : 각 데이터 그램은 독립적, 순서 없음, 연결 자체가 없음, 각 데이터그램이 서로 다른 경로로 전달되기 때문, 각 요청은 하나의 데이터그램보다 작아야함 (65507바이트) 
  • 흐름제어 : 없음, 윈도우 매커니즘 없음 (버퍼 사용 X) -> receiver 오버플로우 발생 가능 
  • 오류제어 : 없음, sender는 메시지가 중복되거나 손실되어도 모름 -> unreliable
  • 혼잡제어 : 없음
  • encapsulation, decapsulation : 프로세스간 메시지 전달 할때 캡슐화
  • queueing : 일부는 구현, 또는 각 프로세스와 관련된 incoming 큐만 존재 
  • multiplexing, demultiplexing 
  • simple protocol과 다른 점 = checksum 
• UDP applications
  • 지연시간이 중요한 애플리케이션의 경우 비연결의 UDP 선호
  • DNS처럼 요청이 짧고, 빠른 응답이 필요한 경우 
  • SMTP와 같은 클라이언트 서버 애플리케이션은 UDP 사용 불가 - 멀티미디어 메시지 전송 불가 (TCP만 가능) 
  • 오류 제어 없음 -> unreliable -> 메시지 손실 가능성 높음 

3.2 TCP (Transmission Control Protocol)

• Stream Delivery Service
  • 바이트 스트림으로 데이터를 보냄 
  • 각 송신 수신측 버퍼 : 동시에 X, 같은 사이즈 아닐 것임 
  • 세그먼트 : TCP에서 패킷을 여러 바이트로 그룹핑한 단위
  • TCP는 각 세그먼트에 헤더를 추가함 
• Full-duplex communication : 데이터가 양방향에서 동시에 흐를 수 있음
• sender가 multiplexing, receiver가 demultiplexing
• 연결 지향 서비스 : 두 프로세스간 논리적 연결 생성 후 양 방향간 데이터 교환 후 연결 종료
• reliable 
• sequence number : 보내지는 각 세그먼트마다 시퀀스 넘버 할당, 0~2^32-1 사이의 임의의 숫자를 초기 숫자로 할당
• example ) 5000바이트의 파일을 전송하는 경우 TCP에서 첫번째 바이트는 10,001, 데이터가 각 1000바이트를 가진 5개의 세그먼트로 보내질 때 각 세그먼트의 시퀀스 넘버는 ? 
  => 

• segment 

• pseudo header : ip 패킷의 헤더 부분 , 프로토콜 필드 = 6 

• 연결 만들기 : Three-way handshaking 
  • 클라이언트 호스트가 TCP SYN 세그먼트를 서버로 보냄 (데이터 없이 imaginery 바이트 하나를 보냄) 
  • 서버 호스트가 SYN을 받고, SYN+ACK 세그먼트로 응답 (one imaginary byte) 
  • 클라이언트가 SYN+ACK를 받고 ACK 세그먼드로 응답 (no data) 
  • => connection open 
• 데이터 전송 : 연결 성립 ~ 연결 종료 
  • PUSH flag : TCP 받는 쪽이 받으면 set
  • URG (urgent) bit = URG bit을 set 하고 세그먼트를 보냄, 세그먼트 시작 부분에 uergent data,  그 끝에 urgent pointer 필드 정의

• 연결 종료 : Three-way handshaking 
• RST (reset) flag : 연결 요청 거부, 현재 연결 버리거나 이상한 연결 버릴 경우 플래그 set
• receive window size (rwnd) = buffer size - pull되는 대기 바이트의 수 

3.3 State transition diagram

• example problem

• 송수신 측 각각에 send recieve 윈도우 = 총 4개
• receive window = rwnd = buffer size - pull 기다리는 바이트 수 

3.4 Flow control

흐름제어는 receiver가 데이터를 사용할 수 있는 비율과 sender가 데이터를 생성하는 비율의 균형을 맞추는 것

• TCP 는 송수신 측 모두 윈도우 사이즈를 조절하도록 강제한다. 
  • receiver window
    -> sender로부터 더 많은 바이트가 오면 close = left에서 right로 이동
    -> 프로세스로 부터 더 많은 바이트가 pull 되면 open = right to left
  • send window
    -> receiver에 의해 조절됨
    => 보내도 된다는 새로운 ack가 오면 close (new ack + new rwnd + last ack + last rwnd)
    => rwnd 사이즈가 조절되어도된다고 허락하면 open (new ack + new rwnd > last ack + last rwnd)
• example

클라이언트 -> 서버 단방향 소통, 양단에 오직 하나의 윈도우만 보이고, 오류는 없다고 가정한다. 

 

• 클라이언트가 seqNo = 100 인 SYN 패킷을 보냄
• 서버는 seqNo=1000, ackNo=101, rwnd를 추가해서 응답함 (SYN+ACK)
• 서버 ACK를 받은 클라이언트는 ackNo, rwnd를 보내고, 데이터 200 바이트를 보냄 
• 200 바이트를 받은 서버는 윈도우 사이즈 200이 줄어 rwnd가 600바이트가 됨 101데이터를 받은 200 바이트가 outstanding 데이터가 되는 것 
•  서버가 ACK에 rwnd를 함께 보내고, 클라이언트도 윈도우 사이즈를 600으로 조절
• 그 다음 데이터를 또 보내면서 위 과정 반복 
• 받을 수 있는 윈도우 사이즈가 계속 줄어들다가 서버에서 데이터를 소비하면 윈도우가 다시 늘어남 

 

• receiver 윈도우는 줄어들 수 없으나 sender 윈도우는 받는쪽인 rwnd를 정의하면 줄어들 수 있다. 
  • new ackNo + new rwnd < last ackNo + last rwnd인 경우 

3.5 Error Control

• TCP는 오류 제어를 하여 신뢰성 제공
  • checksum은 붕괴된 세그먼트를 확인하는데 사용
  • ack는 데이터 세그먼스를 받았는지 확인하는데 사용 
  • retransmission은 오류 제어의 핵심으로 타이머가 만료된 것이나 ACK가 3번 중복되어 받은 경우 retransmission
  • out of order segment는 전달되는 데이터가 순서대로 전달되는지 보장하기 위해 지연시팀
  • FSMs for Data transfer in TCP (finite state machine) 
• Acknowlegement
  • cumulative : 특정 바이트, 순서 넘버가 없는 것
    • 받는쪽이 다음에 받기로 예상하는 바이트를 알림
    • 세그먼트의 중복, 속실 등을 알리는 피드백 없음
    • TCP 해더의 ACK 필드에 ACK=1 인 경우에만 유효함 
  • Selective ACK (SACK)
    • ACK를 대체하진 않음
    • 추가 정보를 알림
    • TCP 헤더의 끝에 옵션으로 추가될 수 있음 
  • ACK 생성 규칙
    • 보내는쪽은 반드시 ACK를 데이터 세그먼트에 포함시켜야 함
    • 받는쪽은 순서가 맞는 oustarnding 세그먼트가 하나뿐일 때는 ACK 보내는 걸 지연시켜야 함 (일정 시간 또는 다른 세그먼트가 올 때까지)
    • 받는쪽은 다음 올 seqNo를 알리기 위해 ACK를 즉시 알려야 함 
      • 받는쪽이 예상하는 seqNo를 가진 세그먼트가 도착하고, 이전 세그먼트가 ACK되지 않았을 경우
      • 순서가 틀린 세그먼트가 왔을 경우
      • 손실된 세그먼트가 왔을 경우
      • 중복된 세그먼트가 왔을 경우
• Retransmission
  
  • RTO : retransmission time out
  • sending TCP는 각 연결마다 하나의 RTO를 유지함
  • 타이머가 만료되면 TCP는 큐의 앞 부분에 있는 세그먼트를 다시보내고, 타이머를 재시작함
  • RTP는 세그먼트의 round-trip time에 의존하여 동적임
    • RTT는 세그먼트가 목적지에 도달하기 위해 필요한 시간으로 ack를 받기 위해 필요한 시간이다
  • 세번의 중복된 ACK 세그먼트가 있으면 retransmission 
    • time out을 기다리지 않고 
    • fast ! 하게 재전송
• example

양단간 쌍방향 소통 - normal operation

• ack = 4001을 보냄 (보내는쪽은 반드시 포함시켜야함) 
• 받은 쪽은 ack로 받은 값부터 seqNo 데이터를 보내고 ack를 보냄
• 받는쪽 세그먼트 하나뿐인 경우 지연시킴 그리고 다음ack를 보내고
• 반복 

 

 

lost segment / 단방향 데이터 전송 

• 손실 발생했는데 sender가 다음걸 보냄 
• out of order가 발생했음을 안 받는쪽은 이전 ack를 다시 보냄
• 이전 ack를 다시 받은 보내는쪽은 seqNo보다 받은 ack가 더 작은걸 알면 이전걸 다시 보냄

 

 

 

 

 

• TCP Congestion Control 
  • 양단에는 congestion 없으나 중간에 있음
  • 받는쪽 윈도우는 TCP가 보내는 바이트로 오버플로우 되지 않음을 보장함
  • TCP는 congestion 윈도우를 사용함 cwnd : 네트워크 상에서 congestion 상황에서 사이즈가 조절됨 
  • 실제 윈도우 사이즈는 rwnd와 cwnd 중 작은 것을 의미하는 것
  • congestion detection 
    • 타임아웃 = strong congestion 을 의미함
    • 세번의 중복된 ACK를 받는 것은 waek congestion을 의미함 
  • congestion 정책 
    • slow start : exponential increase /  ACK가 오면 cwnd += 1
    • congestion avoidnace : additive increase / ACk가 오면 cwnd += 1/cwnd / 일던 threshold를 cwnd가 넘으면 증가 추세를 느리게 함 
  • fast recovery 알고리즘은 옵션 
    • weak congestion  => cwnd += (1/cwnd) 
  • Policy Transitioin
    • Taho TCP
    • Reno TCP 
    • NewReno TCP 
    • AIAM : additivie increase, multiplicative decrease (톱니 모양 / ack가 오면 additive (linear) increase, congestion 감지되면 절반으로 감소시킴) 
• TCP Throughput  = (0.75)W(max) / RTT (round trip time)
  • W(max) = congestion이 발생할 때 윈도우 사이즈의 평균 

 

• TCP Cubic 
  • 보내는 속도의 곡선이 cubic function을 그림 
  • Cubic은 높은 스루풋을 목적으로 함
  • Wmax는 congestion이 감지되었을 때 보내는 속도
  • 손실로 절반으로 속도가 줄었을 때 Wmax에 다시 도달할 수 있게함 

 

3.6 진화하는 전송 계층의 기능

• TCP의 문제 : 3번의 핸드쉐이크 등으로 지연시간과 오버헤드 큼 -> QUIC 등장 
• QUIC : Quick UDP Inernet Connection 
  • UDP 기반
  • 연결을 하는데 지연시간 짧음
    • 연결을 위한 핸드쉐이크 + authentication + encrytion 
    • transport layer security (TLS) : 보안을 위해 별도로 수행했으나 QUIC는 X
  • head of linke blocking (HOB) 없이 멀티플렉싱 가능
    • 하나의 UDP 연결로 multiple stream 전송 가능 
    • stream 사용 
    • 오버헤드가 적음
    • HOB가 앞을 막으면 뒤에 블럭들도 전송될 수 없었는데 HTTP3에서는 가능! 
  • connection migration
    • TCP는 5개 튜플로 연결을 식별 (srcIP, dst IP, port#s, protocol) 
    • QUIC는 연결 아이디만 사용 -> 클라이언트가 연결 중에 IP 주소를 바꿔도 재연결하지 않아도 됨 !! 
  • 보안 개선
  • 혼잡 제어 향상
  • forward error correction 

 

---

References

• 성균관대학교 소프트웨어학과 추현승 교수님 2021-1 컴퓨터 네트워크 개론 
• 2021.03.29
• 2021.04.05
• 2021.04.13