Transport Layer
- Network Layer에서 제공하는 서비스를 Application Layer에서 사용 가능 하도록 변환한다.
- 다른 Host에서 동작하는 Application proccess 사이의 논리적-커뮤니케이션(Logical-Communication)을 제공한다.
- Transport protocol이 End system에서의 Action
- Sender : Application 메시지를 세그먼트(Segment)로 분리하여 Network layer에게 보낸다.
- Receiver : 분리된 Segment를 메시지로 새로 합쳐서 Application layer로 보낸다.
- TCP와 UDP가 대표적인 예시
Transport layer
Network layer
Transport Layer Action
송신자
- Application layer 메시지를 받는다.
- Segment header의 Field value를 정한다.
- Segment 생성
- Segment를 IP로 보낸다.
수신자
- IP로부터 Segment를 받는다.
- Header value를 확인한다.
- Application layer 메시지를 추출(Extract) 한다.
- 소켓을 통해 Application으로 메시지를 Demultiplex 한다.
두가지 중요한 Transport protocol
TCP Transmission Control Protocol
- 신뢰성 있고 순서가 유지된다.
- 혼잡제어
- 흐름제어
- 연결 설정 과정이 있다.
- 데이터 경계가 없다.
UDP User Datagram Protocol
- 신뢰성이 없고 순서가 유지되지 않는다.
- 데이터 경계가 있다.
- 거품이 없는(no-frill) 최선의 노력을 다하는(Best-effort) IP의 확장(Extension)
둘 다 불가능한것
Multiplexing
Sender
- 여러 소켓으로부터 전달된 데이터를 관리(Handle)하여, Transport header를 붙힌다.
- Transporter header는 Demultplexing에 사용된다.
Demultiplexing
Receiver
- 헤더에 적힌 정보를 이용하여 전달받은 Segment를 올바른 소켓에 배송한다.
작동법
- Host가 IP Datagram을 받는다.
- 각각의 데이터그램은 아래의 값을 가진다.
- 송신IP, 수신IP
- 1개의 Transport layer segment
- 송신 포트번호, 수신 포트번호
- Host는 IP주소와 포트번호를 이용하여 Segment를 올바른 소켓으로 전달한다.
Connectionless Demultiplexing
- 소켓 생성시 자기 자신(Host-local)의 포트번호를 작성해야 한다.
- UDP 소켓으로 전송할 Datagram 생성시 목적지의 IP주소와 포트번호를 작성해야 한다.
- 수신자가 UDP Sement를 받으면 수신자 포트 번호를 확인해 올바른 소켓에 보낸다.
- 목적지 IP, 포트가 같은데 Source가 다른 경우에도 같은 소켓에 전송됨
Connection-oriented demultiplexing
TCP 소켓은 다음과 같은 4개의 값(4-Tuples) 으로 구분된다.
- Source IP 주소
- Source 포트번호
- Destination IP 주소
- Destination 포트번호
이 4개의 값을 전부 받아 Segment를 올바른 소켓으로 보낸다. - Demux
- TCP는 여러개의 소켓 작동을 지원한다.
- 각각의 소켓은 자신만의 4-Tuple로 구분된다.
- 각각의 소켓은 다른 연결된 Client와 관련있다.
UDP User Datagram Protocol
- "장식이 없는/no frills", "기본적인/bare bone" 인터넷 프로토콜
- Connectionless Transport
- 최선을 다하는(Best-effort) 서비스로, UDP Segment는 손실되거나 순서가 뒤바뀐채로 App에 전송될수 있다.
- 보통은 제어 정보를 의미합니다. 주소, 오류 검출 코드, 프로토콜 제어 정보등이 있습니다. 이러한 정보를 붙이는 것을 캡슐화라고 합니다.
Service Data Unit
- 전송하려는 데이터를 의미합니다.
- length : 자기 자신의 크기
- checksum : 에러 체크
사용
- 멀티미디어 스트리밍 앱 < 손실은 괜찮고 속도는 빨라야함 >
- DNS
- SNMP
- HTTP/3
특징
- 연결 수락 과정이 없음 ( RTT 낭비 없음 )
- Connection state가 없어 간단함
- 헤더 크기 작음
- 혼잡제어 기능이 없다.
UDP에 신뢰성있는 전송이 필요할 경우 ( ex. HTTP/3 )
- Application layer에 필요한 신뢰성을 추가한다.
- Application layer에 혼잡제어를 추가한다.
- QUIC
실제 사용시
Sender
- Application message를 받는다.
- UDP Segment 헤더를 정한다.
- UDP Segment 를 생성한다.
- Segment를 IP로 보낸다.
Receiver
- IP로부터 Segment를 받는다.
- 헤더값의 UDP Checksum을 확인한다.
- Application layer 메시지를 추출한다.
- 소켓을 통해 Application message를 Demultiplex 한다.
UDP Checksum
- 전송받은 Segment에서 에러(Ex. Flipped bit)를 검출한다.
Sender
- UDP Segment의 Content를 16비트 정수의 나열로 취급(Treat) 한다.
- Checksum : Segment content의 합
- 체크섬의 값은 UDP Checksum field에 넣는다.
Receiver
- 받아온 Segment의 Checksum을 계산한다.
- 계산된 Checksum과 실제 checksum을 비교하여 같으면 에러가 없는것이고 다르면 에러가 있는것이다.
- 물론 같아도 에러가 있을수 있다 : 2비트 이상의 에러가 있는 경우
- Checksum을 계산하는 과정에서 덧셈의 MSB에 비트가 초과할수 있는데, 이는 다시 1의자리로 넘겨 더해준다.
UDP의 장점
- Setup / Handshaking과정이 없다 -> RTT 발생(incurred) 하지 않음
Reliable Data Transfer
- 송수신하는 Channel은 패킷 손실, 패킷 오염, 순서 섞임 등의 비신뢰적(Unreliable) 특성을 가진다.
- 송신자와 수신자는 서로의 상태를 알지 못한다
- 단방향 데이터 전송을 고려해 만든다.
Reliable data transfer protocol (rdt) 인터페이스
- 각각의 API 정의
- 헤더/Protocol Control Information 추가
FSM / Finite state machine
예시
rdt1.0 : Reliable Channel & Reliable Transfer
- Channel에 Bit error도 없고 Packet loss도 없다.
- 즉, 채널이 완전무결하다.
- rdt_send()로 전송 요청시 패킷을 만들어 udt_send()로 보낸다.
- rdt_rdv()로 받아올시 여기서 패킷을 Decapsulation 해 전달한다.
- 수신할때 검사하지 않고 바로 추출및 받는다.
rdt2.0 : Channel with bit error
- Channel에 Bit flip이 생길수 있다. > 에러가 생길수도 있다.
- Checksum과 같은 방식으로 Bit error를 감지할수 있다.
- 이 에러를 복구하는 방법
- ACK : 수신자가 송신자에게 패킷을 잘 받았다고 직접적으로 이야기한다.
- NAKs : 수신자가 송신자에게 패킷에 에러가 있었다고 직접적으로 이야기한다.
- NAK를 받은 송신자는 패킷을 재전송한다.
- STOP AND WAIT
- 송신자가 패킷을 하나 보내고 수신자의 응답을 기다린다. 재전송 방식중 하나.
Sender
- rdt_send() - 전송
- ACK나 NAK을 기다림
- ACK면 다음패킷 전송, NAK면 재전송
Receiver
- rdt_rcv() 수신
- 잘 왔으면 ACK 보내주고 에러 있으면 NAK 보내줌
rdt 2.1 : ACK가 오염된다면?
- 송신자는 수신자에게 어떤일이 일어났는지 알수 없다.
- 그저 새로 보낸다 -> 중복 패킷이 전달될수 있다.
어떻게 처리? - Stop and Wait에서의 사례.
보내 놓고 ACK 올때까지 기다린다.
- 송신자가 중복된 패킷을 보낼때 각각의 패킷에 번호(Sequence Number)를 붙힌다.
- 2개의 번호면 충분하다
- 새로 전송하기 전에 ACK를 확인하고 보내기 때문에 이미 전송된 패킷은 단 한개 뿐이기 때문이다.
- 수신자는 번호를 확인해 중복된 패킷을 버린다.
- 1번 받아야 하는데 0번 오면 버림.
- 수신자는 ACK/NAK가 손상된 사실을 모른다.
- 이전에 보냈던 패킷의 번호를 기억해야 하기에 상태(State)가 두배가 된다.
Sender
Receiver
rdt 2.2 : NAK-Free protocol
- rdt2.1과 유사하게 작동하나 ACK만을 사용한다.
- NAK 대신 수신자는 마지막 패킷을 잘 받았다고 보낸다.
- 이때 ACK에 마지막으로 받은 패킷의 번호를 붙힌다.
- ACK(1) - 1번 패킷을 잘 받았다는 의미
- 1번 패킷 보냈는데 ACK(0)을 보냈다는것은 1번 패킷을 받지 못했다는것과 동일하다.
- 수신자가 ACK를 받았을때 번호가 중복될 경우 재전송한다.
rdt 3.0 : 에러와 손실이 있는 Channel
- 수신자가 ACK를 "적당한 시간"(Reasonable time) 만큼 기다린다.
- 패킷이나 ACK가 너무 늦게오면
- 재전송이 발생한다.
- 이를 위해 반드시 수신자는 받은 패킷의 번호를 ACK에 적어줘야 한다.
- 전송과 동시에 타이머가 시작한다.
- ACK를 받으면 타이머가 사라진다.
rdt 3.0의 성능 ( Stop-and-Wait )
- U_sender : 송신자가 보낸다고 바쁜 시간의 비율
- 예시
- 1Gbps Link, 15ms prop delay, 8000bit packet
- transmission delay는 0.008ms
- 전송에 걸린 시간 / 전체 걸린 시간
- L / R -> Transmission delay
- RTT = 2 * Propagation delay
- Stop-and-Wait의 성능은 너무 별로다,
- 프로토콜이 성능을 제한하게 된다.
rdt 3.1 : Pipelined protocols operation
- pipelining : 송신자가 여러개의 ACK가-곧-될(yet-to-be-acknowledged) 패킷을 보낼수 있게 한다.
- Utilization이 그나마 나아진다.
- 최대 한번에 Propagation Delay / Transmission Delay 개를 보낼수 있다.
Data Link 계층에서는 Stop-and-Wait을 Automatic Repeat reQuest / ARQ 라 부른다.
Go-Back-N
Sender
- Window : 한번에 ACK 없이 전송 가능한 최대의 크기
- 송신자 입장에서 N개 길이의 연속적으로 전송되나 ACK되지 않은 패킷을 가짐
- cumulative ACK
- ACK(n): n번 패킷까지 잘 받았다는 의미
- ACK(n)을 받으면 n+1자리로 Window의 시작점을 옮겨준다.
- ACK 되지 않은 가장 오래전에 전송된 패킷을 기준으로 타이머가 동작한다.
- Timeout 발생시 ACK를 받지 못한 가장 오래된 n번째와 Window 에 포함된 이후 패킷을 전송한다.
Receiver
- 현재까지 잘 받은 패킷의 ACK만 보낸다. 보내는 ACK의 번호는 가장 순서가 높은 번호를 보낸다.
- 중복 ACK를 보낼수도 있다, rcv_base가 기억해야한다.
- 순서가 올바르지 않은 패킷을 받을떄
- 버리거나 버퍼에 저장한다.
- 순서가 올바르지 않기 직전 가장 높은 패킷 번호로 ACK를 보낸다.
- 송신자가 재전송을 한다.
Selective repeat
- 수신자가 모든 제대로 받은 패킷에 대해 개별적으로 ACK를 보낸다.
- Cumulate ACK가 아니다!
- 필요하면 패킷을 버퍼에 저장한다.
- 송신자는 ACK되지 않는 패킷을 따로 재전송한다.
- 송신자는 각각의 ACK되지 않은 패킷의 타이머를 보관해 둔다.
- 모든 전송되는 패킷에 Timeout 을 측정한다!
- 송신 윈도우
- N개의 연속된 번호
- 보내는 양에 제한을 둔다.
pkt2의 ACK가 오지않아 Timeout 된 예시
selective repeat dilemma
- 받는 입장에서 패킷이 재전송된 이전 패킷인지 새로 전송된 다음 패킷인지 알수 없는 문제 발생
- 순서번호가 윈도우에 비해 너무 작기 때문에 벌어지는 일
- 순서번호의 갯수를 윈도우 크기의 2배와 같거나 크게 해주면 된다.
TCP
TCP SEGMENT 구조
RST-유효하지 않은 연결 거부, SYN-연결시작시 1로 설정, 첫번째 전송 위치를 주고받음, FIN-연결 종료에 사용한다.
ACK에 대한 ACK는 받지 않는다.
Flow Control : 수신 측에서 받을수 있는 바이트의 수, option에 이 값에 곱할수 있는 scaling factor를 적어 놓을수 있다.
C, E : 혼잡제어에 사용
P : 바로 수신되어야 되는 데이터인지 확인, 어플리케이션이 바로 필요한 데이터인지
U : Urgent pointer가 유효한 것인지를 나타낸다. Urgent pointer란 전송하는 데이터 중에서 긴급히 전당해야 할 내용이 있을 경우에 사용한다. 긴급한 데이터는 다른 데이터에 비해 우선순위가 높아야 한다.
- Point to Point (점대점 연결)
- Reliable / In-order byte (신뢰성 있고 순서유지됨)
- no Message boundary
- 송신 함수의 호출 횟수와 수신 함수의 호출 횟수가 일치하지 않아도 된다 == 데이터의 경계가 없다
- 보낸 문자열들을 한번의 수신함수 호출로 전부 받아올수 있다.
- Full duplex data
- 동일 연결로 양방향 데이터 전송
- MSS : Maximum segment size
- 1 Segment의 최대 크기가 제한된다.
- 네트워크 카드의 MTU를 기준으로 정해진다.
- Cumulative ACK
- Pipelining
- TCP 혼잡/흐름 제어를 통해 윈도우 사이즈를 결정한다.
- Connection-oriented:
- 논리적 Connection 이 생성되고 데이터가 송수신된다.
- Handshaking(Control message exchange)가 데이터 교환 이전에 성사된다.
- Flow controlled
- 송신자가 수신자의 버퍼가 넘치지 않게 한다(Overwhelm)
TCP 패킷 구조
- Sequence number
- Sequential Number : 송신시 전송하는 시작 바이트의 순번
- ex) 300byte 의 데이터를 100byte 씩 나눠서 보낼 때 첫 패킷은 0, 두번째는 100, 세번째는 200 이다.
- Acknowledgement
- 상대방이 다음에 전송해야할 순서번호
- 패킷을 잘 받았으니 다음 패킷을 보내라는 뜻이다.
- 순서가 다른 Segment의 처리
- TCP로 처리 불가능, Implementor에 따라 다름
- Checksum
- IP정보를 포함하는 Pseudo-header를 포함하여 계산한다.
- options와 header length
- options를 포함한 헤더의 길이를 ACK 바로 아래 head len 에 기록한다.
- head len의 길이의 제한으로 options 부분의 길이는 제한된다.
Piggybacking - 데이터 전송과 ACK를 동시에 하는것 - TCP
- 이를 위해 ACK와 Seq number가 전부 Segment에 존재한다!
- 양방향으로 ACK는 받은 Seq 번호 + 1이 되는것을 볼수 있다!
TCP Timeout
- RTT보다는 길어야 한다, 즉 갔다가 오는 시간보다는 길어야 한다는것. 허나 RTT는 항상 다르다!
- TCP Timeout이 너무 짧으면
- 너무 빠른 Timeout 발생한다.
- 불필요한 재전송이 발생한다.
- TCP Timeout이 너무 길면
- Segment loss에 대해 늦은 반응을 보인다.
RTT 예측법
- SampleRTT
- segment가 전송되고 ACK를 받기까지의 시간을 측정한다.
- RTT를 Smoother하게 예측할수 있다.
- 최근 측정된 값들의 평균을 사용하는것.
- α : 새로 측정된 시간의 가중치, 보통 0.125를 사용한다.
- Timeout Interval
- Estimated RTT + "Safety Margin"
- Safety margin
- 보통 EstimatedRTT의 편차(DevRTT) * 4의 값을 사용한다.
- 편차 계산 : 차이의 절댓값을 사용한다는것을 주의한다.
- β 의 값은 보통 0.25 정도이다.
TCP sender
- Sequential Number를 이용해 Segment를 만든다.
- 타이머가 실행중이지 않으면 시작한다.
- 타이머는 가장 오래된 ACK를 받지못한 Segment를 위한것이다.
- 타이머 구간 벗어남 : TimeOutInterval
Timeout
- 타임아웃을 일으킨 Segment를 재전송한다.
- 타이머 재시작
ACK 받음
- ACK 받았다고 Update한다.
- ACK 못받은게 여전히 있으면 타이머를 시작한다.
TCP Receiver
Event
-
Segment가 순서대로 예상한 Seq Number과 함께 도착. 예상한 Seq Number까지 이미 ACK 보냈음
-> ACK 지연, 500ms정도 다음 Segment를 기다리다가 안오면 ACK를 보내서 요청함
-
Segment가 순서대로 예상한 Seq Number과 함께 도착. 한 Segment가 ACK를 보내지 않았음
-> 즉시 단일 ACK를 전송 및 요청
-
Segment가 마구잡이로 예상보다 큰 Seq Number과 함께 도착.
-> 즉시 중복 ACK를 보낸다. 이는 받기를 예상한 byte의 Seq Number이다.
- 마지막 ACK ( ACK=120 )은 92는 이미 받았고 내가 필요한건 120 Seq Number Segment라는것이다.
- Cumulative ACK 덕분에 오류가 발생하지 않았다.
TCP fast retransmit
- 만약 송신자가 똑같은 데이터를 요청하는 3개의 ACK를 받았을 경우 ACK 되지 않은 가장 작은 Seq Number를 가진 Segment를 전송한다.
TCP Flow control
- Network layer가 Application layer에서 가져가는것보다 데이터를 더 빨리 가져온다면?
-
receive window / rwnd : 수신자가 받아오기를 희망하는 바이트 크기를 지정한다
-
수신자가 송신자를 관리해, 송신자가 너무 많은 데이터를 빠르게 전송해 버퍼 오버플로우가 생기는것을 방지한다.
HOW
- TCP 수신자가 rwnd 필드를 통해 사용 가능한 버퍼 공간의 크기를 공시(Advertise) 한다.
- RcvBuffer : 수신버퍼, OS에 의해 자동으로 조절되며 대체로 4096바이트.
- 수신자는 rwnd값을 토대로 전송되는/ACK를 받지못한 데이터의 양을 조절한다.
- 수신 버퍼가 오버플로우 되지 않도록 보장한다.
TCP Connection Management
- 데이터 교환하기 이전에 송-수신자들은 Handshake를 한다.
- 연결을 성사하기 위한 동의
- 시작 Sequential Number과 같은 Parameter들에 대한 동의
2-way handshake
- 서버가 클라이언트에 패킷을 보내는 SYN이 없다.
TCP 3-way handshake
- Client가 SYNbit를 1로 하고 Seq x를 정해 요청
- Server가 SYNbit를 1로 하고 Seq y를 정해 요청과 동시에 ACK는 x+1을 보냄 ( 다음 바이트 순서 요청 )
- Client가 ACK를 y+1로 해서 보냄
belay 자일을 매다
TCP 연결 닫기
- Client와 Server 모드 자신의 연결을 닫는다.
- FIN을 받아 ACK로 응답한다.
- FIN을 받았을시 ACK는 자가 자신의 FIN과 같이 보낸다.
- 동시적인 FIN 교환이 이루어진다.
Congestion Control 혼잡제어
Congestion
- 네트워크가 감당하기엔 너무 많은 Source가 너무 많은 Data를 빠르게 보내는것.
- 증상
- 긴 딜레이 : 라우터 버퍼에서 기다리는 시간
- 패킷 손실 : 라우터에서 버퍼 오버플로우
예시 1
- R의 속도를 가지는 단일 라우터에 N개의 연결이 존재
- 사용하는 대역폭이 R/2를 넘어서는 순간
- 나가는 속도보다 들어오는 속도가 더 빨라져 딜레이가 무한이 된다.
예시 2
- 버퍼가 한정된 라우터의 경우
- 송신자가 손실되거나 타임아웃된 패킷을 새로 보낸다.
예시 3
- 송신자는 라우터 버퍼가 있을때만 데이터를 보낸다.
예시 4
- 패킷이 손실될수도 있다
- 송신자는 패킷이 손실되었음을 알았을때에만 재전송한다.
- but sender times can time out prematurely, sending two copies, both of which are delivered
"Congestion"의 COST
- 주어진 수신 Throughput에 대해 재전송으로 인한 더 많은 작업량
- 필요하지 않은 재전송
최대 Throughput보다 느리게 된다.
예시 5
- 빨간색 in이 늘어나면 윗쪽의 패킷은 drop된다
- 파란색 Throughput은 0이 된다.
- X 축 : 보내는 양 | Y축 : 받는 양
- 또다른 Congestion의 cost
- 패킷이 손실되면 거기까지 가는데 소요된 버퍼와 송신 대역은 낭비된 셈이 된다.
정리
-
Throughput은 Capacity를 넘을수 없다.
-
Capacity에 도달하면 Delay가 증가한다.
-
패킷손실/재전송은 실질 Throughput을 감소시킨다.
-
필요하지 않은 재전송 또한 실질 Throughput을 감소시킨다.
-
패킷 손실이 일어날 경우 그간 사용된 버퍼와 대역폭은 낭비된것이 된다.
해결 - 시험에 나올듯
End-End congestion control
- 패킷 손실과 패킷 지연을 통해 혼잡 상태를 추정한다.
- 직접적인 정황이나 피드백은 없다.
- TCP에 의해 작동된다.
Network assisted congestion control
- 라우터가 직접적으로 송수신 호스트에 피드백을 보낸다.
- Congestion level이나 sending rate을 정해준다.
- TCP ECN, ATM, DECbit
TCP Congestion control
AIMD - Additive Increase Multicative Decrease : 선형 상승 지수 하강
- 송신자는 패킷 손실이 일어나기 전까지 송신 속도를 올리다 패킷 손실이 일어나면 줄인다.
- 세번 중복된 ACK 받으면 속도를 절반으로 줄인다.
- 타임아웃으로 손실되면 1개의 최대 세그먼트 크기(MSS / Maximum Segment size)정도로 속도를 줄인다
AIMD : Distributed Asynchronous Algorithm
- optimize congested flow rate
- desirable stability
Detail
- cwnd바이트만큼 보낸 뒤 ACK를 기다리기 위해 RTT만큼 기다린다
- 더 많은 데이터를 전송한다.
- 파일 전송 제한
- cwnd = 마지막으로 보낸양 - 마지막으로 ACK된양
- 증가량은 cwnd보다는 작거나 같아야 한다!
TCP slow start
- 처음엔 1 cwnd만큼 보냈다 다음엔 2배로 늘려나간다.
- 느렸다가 매우 빨라진다.
- 지수적인 속도 증가가 linear해야 할 타이밍은?
- slow start threshhold / ssthresh를 정해서 결정한다.
구현
- ssthresh 변수 정함
- 패킷 손실시 ssthresh는 패킷 손실 직전 속도의 절반이 된다.
- reno와 tahoe는 방식의 이름중 하나이다.
TCP Cubic
- AIMD보다 더 나은 방법
- W_max : 패킷 손실이 측정된 속도
- W_max가 그리 크게 변하지 않았을것이라 예측함
- 절반으로 속도가 줄어들었으면 빠르게 Wmax에 가깝게 속도가 늘어나되, 근처에 다가가면 다시 속도증가가 느려짐
이름 외우기_
- K : TCP 윈도우 사이즈가 W_max에 도달하는데 걸리는 시간
Bottleneck link
- TCP 속도가 특정 라우터의 패킷 손실이 일어나기 전 까지 증가 : 병목 Link가 존재한다.
Delay-based TCP congestion control - tcp-vegas
- 측정 처리량 : 측정된RTT마지막RTT에전송된바이트
- RTT_min : 최소 측정 RTT
- 혼잡이 없을때 얻을수 있는 가장 큰 처리량은 cwnd/RTT_min
- 측정 처리량이 비혼잡에 가까울 경우 cwnd를 증가
- 측정 처리량이 혼잡에 가까울 경우 cwnd를 감소
- 손실을 강제하지 않는 congestion control
- 지연시간을 최대한 적게 유지하면서 처리량을 최대로 함
tcp-bbr : 구글에서 만듦
Explicit congestion notification ( ECN )
Network Assisted congestion control
- IP 헤더의 두 비트(ToS/Type of Service 필드)가 네트워크 라우터에 의해 혼잡 정도를 확인하는 용도로 사용된다.
- 혼잡 정도가 목적지에 도착한다
- 목적지에서 TCP의 C, E 비트를 설정해 ACK Segment로 보내서 송신지에 혼잡을 공지한다.
- E 비트 : ACK에 담아 보내는 혼잡 알림
- C 비트 : 자신이 E 비트를 받아 cwnd를 줄였음을 알림
- IP와 TCP 모두가 사용된다.
TCP Fairness
- K개의 TCP 세션이 같은 R 대역폭의 bottleneck link를 공유할시 각각의 평균 대역폭을 R/K로 한다.
- 기기가 늘어날수록 대역폭이 줄어든다.
2개의 TCP 세션이 있을때
- 회색 선이 가장 공평하게 대역폭을 분배한 경우이다.
- 불공평 하다가도 congestion control에 의해 점점 공평하게 되어간다.
- UDP의 경우 congestion control이 없어 제외되어 버린다.
- 두 호스트간의 여러 연결이 존재할 경우 연결을 독점할수 있다.
TCP 연결을 여러개 사용한다면
- 많은 연결을 사용하여 더 큰 대역폭을 가져갈수 있다.
Transport layer evolve
개발방향
QUIC : Quick UDP Internet Connections
- Application layer protocol - UDP 사용
- HTTP의 성능 증대.
Error / Congestion control
Connection Establishment
- 1 RTT 안에 신뢰성, 혼잡제어, 인증, 암호화, 상태제어
여러개의 Application level "stream"이 단일 QUIC 연결을 통해 Multiplex된다.