Chapter 2 Transport Layer

提纲

[TOC]

Application layer

1. Application layer

application layer 不是本课重点，所以只用几页ppt简介（高编里重点讲了）

This is the layer you (mostly) work with as a programmer.

At the application layer the “network” is abstracted away and you access a stream of data that arrives at a “socket”.通过套接字socket访问网络层数据流

Different applications have different formats:

• HTTP (Hypertext transfer protocol) world-wide web

• FTP (File transfer protocol) moving data

• SMTP (Send Mail transfer protocol) sending email

• IMAP (Internet message access protocol) receiving email

Sockets

process sends/receives messages to/from its socket

进程通过socket传递信息

套接字 <=> 门户

发送进程将报文推出门户，发送进程依赖于传输层设施在另外一侧的门将报文交付给接受进程

接收进程从另外一端的门户收到报文（依赖于传输层设施）

Addressing processes

进程寻址

to receive messages, process must have identifier

host device has unique 32- bit IP address

identifier includes both IP address and port numbers（进程端口号） associated with process on host.

example port numbers:

• HTTP server: 80

• mail server: 25

Q: does IP address of host on which process runs suffice for identifying the process?

A: no, many processes can be running on same host（一个主机多个进程）

4 different addresses in TCP/IP

Physical address Layer 2

• ==Also known as the link address, is the address of a node as defined by its LAN or WAN==

物理地址称为链路地址，是由接点所在的局域网或广域网为该结点指定的地址。

Logical address Layer 3 (32-bit , IPv4 128-bit IPv6)

• Logical (IP) addresses are for universal communications（全局通信）that are independent of underlying physical networks 与底层物理网络无关

Port address Layer 4 (16-bit)

• Port addresses differentiate different processes

Application-specific address Layer 7 特定应用地址

• Some applications have user-friendly addresses that are designed for that specific application, such as email address, URL.

有些应用程序具有专门为其量身定做的用户友好型地址。

application protocol defines

应用层协议定义了在不同端系统如何传递报文

1. types of messages exchanged

• e.g., request, response

2. message syntax

what fields（字段） in messages & how fields are delineated

3. message semantics (语义)

meaning of information in fields

4. rules for when and how processes send & respond to messages

open protocols:

defined in RFCs (request for comments) 由RFC文档定义

allows for interoperability 允许互操作

e.g., HTTP (web), SMTP (email)

proprietary protocols专用（私有）协议:

e.g., Skype

translation layer

provide logical communication between app processes running on different hosts

send side: breaks app messages into segments, passes to network layer
rcv side: reassembles segments into messages, passes to app layer

network layer: logical communication between hosts

transport layer: logical communication between processes

Multiplexing/demultiplexing

Multiplexing (Mux):

• Combining several streams of data into a single stream.

• Example – your phone is browsing the web, refreshing your email, connecting to WeChat at the same time. All these connections are sent over the same link.

Demultipliexing (Demux)

A stream of data is separated out into its individual components.

The stream of packets the phone received is split up and sent to the appropriate program for web, email, wechat.

multiplexing at sender: handle data from multiple sockets, add transport header (later used for demultiplexing, 提供进程的信息：IP+port)

demultiplexing at receiver: use header info to deliver received segments to correct socket

How demultiplexing works

host receives IP datagrams(数据报：第三层的packet)

• each datagram has source IP address, destination IP address

• each datagram carries one transport-layer segment

• each segment has source, destination port number

无论tcp udp 都有source port and destination port(当然还有其它字段)

host uses IP addresses & port numbers to direct（引导） segment to appropriate socket

Connectionless demux

UDP socket identified by 2-tuple

• checks destination port # in segment

• directs UDP segment to socket with that port #

如果两个不同源IP地址/源端口号的数据报，但是有相同的目标IP地址和端口号，则被定位到相同的套接字（一个UDP套接字是被目标IP与目标port唯一标识的）

IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at dest 具备相同目标IP地址和目标端口号，即使是源IP地址或/且源端口号不同的IP数据报，将会被传到相同的目标UDP套接字上

Connection-oriented demux

TCP socket identified by 4-tuple

( demux: receiver uses all four values to direct segment to appropriate socket):

• source IP address

• source port number

• dest IP address

• dest port number

TCP socket是由四元组（目标ip 目标port 源IP 源port）唯一确定的

一个port可以有多个进程

web servers have different sockets for each connecting client

server host may support many simultaneous TCP sockets:

web servers have different sockets for each connecting client
所以每有一个客户端连接，就新建一个process（p4 p5 p6）

但是进程与socket并不是一一对应关系，当一个进程包含多个thread时可能对应多个socket

Typical port numbers for applications

背一下，可能考

Port 80: Standard HTTP (Hypertext Transfer Protocol – browse the web
Port 22: ssh (secure shell) log in from remote computer
Port 25: SMTP (simple mail transfer protocol) – send mail via this host
Port 143: IMAP (Internet Message Access Protocol) – read your email
Port 443: HTTPS (secure HTTP) browse the web securely

UDP: User Datagram Protocol

Simplest usable Internet transport protocol

“best effort”尽力而为 service, UDP segments may be:

• lost

• delivered out-of-order to app 失序

connectionless:

• no “handshaking” between UDP sender, receiver (can send immediately without asking first)

每个UDP报文段都被独立地处理handled independently

UDP use:

streaming multimedia(流媒体) apps (loss tolerant, rate sensitive)

DNS

NMP

reliable transfer over UDP: 用udp实现可靠传输的方法

add reliability at application layer
application-specific error recovery!应用特定的差错恢复

多了length 和checksum

头部一共8byte

为什么要有UDP(UDP 好处)?

不建立连接（会增加延时）
简单：在发送端和接收端没有连接状态
报文段的头部很小(开销小)也就是报文段可以占更多空间
无拥塞控制和流量控制：UDP可以尽可能快的发送报文段

UDP checksum

Goal: detect “ errors ”（flipped bits 比特翻转）

sender:

treat segment contents, including header fields, as sequence of 16-bit integers.

分成多个十六比特序列
checksum: addition of all of segment contents(各数据段相加回卷反码)
sender puts checksum value into UDP checksum field 把结果放到检验和区域

receiver:

compute checksum of received segment（先用segment compute）
check if computed checksum equals checksum field value: （再和发来的checksum比）

不相同一定传输有错，相同不一定没错

• NO - error detected

• YES - no error detected.

还是有可能有错误：checksum传输错误，payload也错误，并且最后比对结果一致

Principles of reliable data transfer （rdf）

可靠数据传输原理

将较低层直接视为不可靠信道（在不可可靠的下层协议基础上实现reliable data transfer）

**rdt_send():**发送方上层调用，将数据发往接收方application layer

udt_send(): rdt调用将数据发给udt(下层)

**rdt_rcv():**数据到达接收方

**deliver_data():**rdt调用将数据交付更高层

consider only unidirectional data transfer（单向数据传输）因为双向仅仅是重复

rdt1.0: reliable transfer over a reliable channel

完全可靠信道的rdf(假设底层信道完全可靠)

underlying channel perfectly reliable

• no bit errors

• no loss of packets

separate FSMs（Finite State Machine） for sender, receiver
横线上是event横线下是action

独立fsm:

rdt2.0: channel with bit errors

underlying channel may flip bits in packet（下层信道可能发生bit受损）

• checksum to detect bit errors

• acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK

• negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors

• sender retransmits pkt on receipt of NAK(重传)

Sender（状态机上所有信息都是指某一方的）:

当reciver wait for call时，来了一个ACK/NACK ->do nothing（stop-wait）

receiver:

corrupt(rcvpkt)接收方发现分组损坏

fatal flaw： ACK/NAK corrupted，can’t just retransmit: possible duplicate （sender 发送完后等待ACK，此时reciver接收到data但是返回的ack在传输过程中corrupt，发送方被迫重传，造成duplicate）

handling duplicates:

▪ sender retransmits current pkt if ACK/NAK corrupted

▪ sender adds sequence number (seq) to each pkt编号防止重复

▪ receiver discards (doesn’t deliver up) duplicate pkt

sender sends one packet, then waits for receiver’s response

rdt2.1: sender, handles corrupt ACK/NAKs

sender:

receiver:

为什么两个状态数（0 1）就足够？

只需要让发送发知道是在传last packet（seq same）还是 now packet(seq different)
receiver can not know if its last ACK/NAK received OK at sender

接收端无法确定ACK/NAK是否会被发送端接受，通过观察发送端的反应来判断它是否成功收到。

比如：本身应该wait for 1但是由于上一次接收端没收到ack，重新发数据（0）接收端发现发来的不是1，那就明白发送端当时收错了，所以发ACK回去，继续等待1.

只要接收到packet没有corrupt就发ack，不管序号是否正确
状态数量是前者两倍

rdt2.2: a NAK-free protocol

▪ instead of NAK, receiver sends ACK for last pkt received OK

• receiver must explicitly include seq # of pkt being ACKed

不用NAK,而是用一个带序号的ACKA(上一个数据分组的序号)-确认上个分组收到了（没收到现在的分组）

rdt3.0: channels with errors and loss

underlying channel can also lose packets （假设底层也丢包）

approach:

每发一个分组就启动一个倒计时计时器(cutdown timer) 当收到该分组的ACK或重发分组时重建一个计时器

sender waits “reasonable” amount of time for ACK

界定一个合理的时间，如果时间耗尽则界定为丢包——重发该分组

如果这个分组只是delay了（没loss）retransmission will be duplicate, but seq. #’ s already handles this

四种情况：

d接收到ACK1什么都不做（不重发）ppt有点问题

Performance of rdt3.0

3.0 rdt的性能

rdt3.0 is correct, but performance is very bad

Define round-trip-time as time to propagate there and back – (2 x end-to-end delay)

e.g.: 1 Gbps link, 15 ms delay, 8000 bit packet

1Gbps的链路只能每秒发33kB数据，利用率很低

为了解决如上问题使用pipelined protocols不用stop-wait协议

Pipelined protocols

pipelining: Allows a sender to send more than one message at a time without receiving acknowledged

one after one

range of sequence numbers must be increased（每个输送的分组必须有唯一序号）
buffering at sender and/or receiver(缓存那些已经发送但没有确认的分组)（停等协议不需要buffer）

two generic forms of pipelined protocols: go-Back-N回退N步, selective repeat选择重传

slide window流程

发送窗口N=1 接收窗口N=1 此时称为stop-wait

发送窗口N>1 接收窗口N=1 此时称为GBN

发送窗口N>1 接收窗口N>1 此时称为SR

滑动窗口(slide window)：

sender:

未发送任何数据：后沿=前沿 , 之间为发送窗口的尺寸=0

发送窗口的最大值<=发送缓冲区的值

上层传递一个分组，发送该分组但还没确认

前沿移动的极限：不能够超过发送缓冲区

老分组得到确认

发送窗口后沿移动：收到老分组的确认，不能够超过前沿

reciver

接收窗口用于控制哪些分组可以接收；

• 只有收到的分组序号落入接收窗口内才允许接收

• 若序号在接收窗口之外，则丢弃；

也就是说

接收窗口尺寸Wr=1，则只能顺序接收；(GBN stop-wait)

就一个槽位没法接收其他序号

接收窗口尺寸Wr>1 ，则可以乱序接收

低序号的分组到来（0到来）接收窗口移动

如果高序号到来（1先到来）接收窗口不移动直到0到来直接移动到2（一起交付给上层）

（因为要实现rdt，不允许失序）

• 接收窗口尺寸=1 ；发送连续收到的最大的分组确认（累计确认）

看上上图：如果收到3仍然发送0的确认（表示没收到0，重发）

• 接收窗口尺寸>1 ；收到分组，发送那个分组的确认（非累计确认）

收到几就发几

Go-Back-N

sender can have up to N unacked packets in pipeline

receiver only sends cumulative ACK（累计确认：当前序号的分组被acknowledged意味着前面所有序号的分组都被acknowledged）

累计确认：一个确认包确认了累积到某一序号的所有包，而不是对每个序号都发确认包。

分别确认：每个包都单独确认

doesn’t ACK packet if there’ s a gap（如果分组乱序：接收packet1->packet3，则不会acknowledge packet3，会返回packet2继续等待packet2）

sender has timer for oldest unacked packet(发送方对最早发出去的未被确认的数据有计时器，一旦此数据被acknowledged计时停止，如果超时则重发该分组之后所有已发送但未确认的分组，尽管有些序号更大的分组可能已经成功确认)也只有一个计时器

when timer expires, retransmit all unacked packets(重传所有未被确认的分组)

sender：

ACK(n): ACKs all packets up to, including sequence # n -“cumulative ACK（sender）”

• may receive duplicate ACKs (see receiver)
timer for oldest in-flight pkt
timeout(n): retransmit packet n and all higher seq # pkts in window

发送方只维持已发送但未被确认的最小序号

GBN：当发现N没发，就回到N，发N及之后的

Selective repeat

sender can have up to N unacked packets in pipeline
Receiver sends individual ACK for each packet

buffers packets, as needed, for eventual in-order delivery to upper layer
sender maintains timer for each packet with no ACK

• when timer expires（到期）, retransmit only that unacked packet（只重传没有确认的分组）

out-of-order: buffer
in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt

窗口长度必须小于等于序号空间大小一半

第一种情况：pkt3丢失，此时应该传第二轮的pkt0

第二种情况：ack0 ack1 ack2丢失，此时应该传第一轮的pkt0

但是这俩情况无法区分，所以窗口长度必须小于等于序号空间大小一半

TCP （Transmission Control Protocol）

TCP header

头部20B~60B

sequence number:

• byte stream “number” of first byte in segment’s data

本报文段中第一个字节在字节流中的编号（0、1000）

acknowledgements确认号:

•seq # of next byte expected from other side(cumulative ACK)

期望从另一方收到的下一个字节的序号（与rdt不一样）

how receiver handles out-of-order segments

如果以乱序到达，TCP没有规定一定要向GBN一样丢弃PKT,提供可编程实现的操作，可以丢弃也可以保留（后等待前面的到来）

注意区分seq和ack的不同，这里ack是期待的序号而不是本位序号

这个图是一收一发的过程：seq=上一个的ack, 但ack等于上一个seq＋1

TCP round trip time, timeout

how to set TCP timeout value?

如何设置TCP超时等待时间，应该比RTT长，但是RTT随阻塞和负载情况变化

longer than RTT
but RTT varies

too short: early timeout, unnecessary retransmissions

too long: slow reaction to segment loss

how to estimate RTT?

SampleRTT: measured time from segment transmission until ACK receipt

SampleRTT will vary, average several recent measurements, not just current SampleRTT

exponential weighted moving average: 移动平均系统？dsp里那个

influence of past sample decreases exponentially fast 因为只想与最近的值有关（实时更新数据？）

timeout interval: EstimatedRTT plus “safety margin”

EstimtedRTT + 安全边界时间

• large variation in EstimatedRTT -> larger safety margin（变化大边界也设置大一点）

偏移量（实际值与平均值的偏移）：

TCP不同于rdt中每个packet设置一个timer，tcp使用单一的重传定时器。

定时器只与最早的，未被确认的报文有关系

retransmission scenarios

丢包导致超时

过早超时

此时报文段seq=100没有重传，因为在ack=100返回HostA时将再启动一个计时器，上一个计时器结束，这ACK=120在新计时区间里被找到，不用重传

定时器只与seq
累计确认

当第一段报文在网络中丢失，但在超时前主机A收到120号ack,因为是累积确认，所以HostA知道Host B收到了119前的所有数据只会传120

cumulative ACK像GBN

虽然ACK=100没到，但是ACK=120到了，那么sender知道reciver已经收到ack=100,这很像GBN

TCP fast retransmit

不等timeout就重传：

time-out period often relatively long:

• long delay before resending lost packet

detect lost segments via duplicate ACKs

if the segment is lost, there will likely be many duplicate ACKs（接收方反复期待）

if sender receives 3 duplicate ACKs（一共四个） for same data(“triple duplicate ACKs”), resend unacked segment with smallest seq#

三次冗余后才重传

TCP flow control

控制rwnd来控制发送发数据量，防止丢失

receiver controls sender, so sender will not overflow receiver buffer by transmitting too much, too fast

发送方根据接收方的处理能力来发送数据，不会导致接收方处理不过来，是流量控制(这是由接收窗口实现的)

从TCP socket缓冲区中移走数据的速度比接收方交付数据的速度慢

receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments

TCP通过发送方维护一个称为receive window（接收窗口）的变量（TCPpacket头部中一个变量）来提供流量控制，接收窗口用于告诉发送方，还有多少可以用于接收的缓存空间

rwnd = receive window

• RcvBuffer size set via socket options (typical default is 4096 bytes) 接收缓存

• many operating systems autoadjust RcvBuffer

sender limits amount of unacked (“in-flight”) data to receiver’ s rwnd value

guarantees receive buffer will not overflow

MSS and MTU

MSS (Maximum Segment Size最大报文长度) is a parameter specifying the largest amount of data in a single IP datagram that should be sent by a remote host.

报文段里应用层数据的最大长度

MTU is a parameter specifying the largest amount of data that a communication protocol or system can pass onwards. For example, standards (e.g. Ethernet) can fix the size of an MTU, or systems (such as point- to-point serial links) may set MTU at connect time.

MSS size is set according to MTU:

MSS = MTU – IP header size – TCP header size.

Nagle’s algorithm

问题：

TCP will send the data as it arrives at the send buffer if there is space left in the send buffer.
This means (for ssh/telnet) one packet sent every time user hits key.
Overhead of this is huge (TCP header + IP header + frame header to send one byte)

应用程序一次产生一字节数据，这样会导致网络由于太多的包而过载（一个常见的情况是发送端的”糊涂窗口综合症(Silly Window Syndrome)“）。从键盘输入的一个字符，占用一个字节，可能在传输上造成41字节的包，其中包括1字节的有用信息和40字节的首部数据。

Nagle’s algorithm

The sending TCP sends the first piece of data it receives – no matter no small or large
Sending TCP accumulates data in the buffer and waits until one of the following before sending the segment:
- The receiving TCP sends an ACK
- Data has accumulated to fill a maximum size segment （数据达到MSS）
Repeat step 2

当需要较快的交互/需要传递small pkt时不用Nagle’s algorithm

Silly Window Syndrome

糊涂窗口综合症是指当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢，或二者兼而有之；就会使应用进程间传送的报文段很小，特别是有效载荷很小；极端情况下，有效载荷可能只有1个字节；传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象。

发送端引起的糊涂窗口综合症

Sender produces data very slowly

接收端引起的糊涂窗口综合症

• Single byte or small number removed from full receive buffer.

• Sender is informed of opportunity to send small number of bytes and immediately sends filling buffer.

• Process repeats

接收端的TCP可能产生糊涂窗口综合症，如果它为消耗数据很慢的应用程序服务，例如，一次消耗一个字节。假定发送应用程序产生了1000字节的数据块，但接收应用程序每次只吸收1字节的数据。再假定接收端的TCP的输入缓存为4000字节。发送端先发送第一个4000字节的数据。接收端将它存储在其缓存中。缓存满了。它通知窗口大小为零，这表示发送端必须停止发送数据。接收应用程序从接收端的TCP的输入缓存中读取第一个字节的数据。在入缓存中有了1字节的空间。接收端的TCP宣布其窗口大小为1字节，这表示正渴望等待发送数据的发送端的TCP会把这个宣布当作一个好消息，并发送只包括一个字节数据的报文段。这样的过程一直继续下去。一个字节的数据被消耗掉，然后发送只包含一个字节数据的报文段。

解决办法– receiver does not advertise windows that would

**cause sender to send small amounts of data.**等buffer空间足够大再发送rwnd的值

Connection Management

连接管理 handshake

agree to establish connection (each knowing the other willing to establish connection)
agree on connection parameters

Q: will 2-way handshake always work in network?

variable delays
retransmitted messages (e.g. req_conn(x)) due to message loss
message reordering
cannot “ see ” other side

req_conn(x)第一次超时，导致重传，然而第一次发出去的req_conn(x)并没有丢失，而是回到sender，与之建立了连接，此时连接x已经完成。但是重传的req_conn(x)到达接收端后，再向发送端发送的ack被拒绝了也就是建立了half open connection持续占用资源

关闭连接后，发送方重传的报文才到达，此时server会误认为又新建一个连接，于是保持一个连接状态，但是client不这么认为（它知道是重传的）所以不会建立连接，白白浪费主机资源

TCP之三次握手和四次挥手 - 掘金 (juejin.cn)

深入浅出TCP三次握手（多图详解） - 知乎 (zhihu.com)

TCP 3-way handshake

将小明当作客户端，小红当作服务器端，两人写信告白：
第一次握手：
小明告诉小红：我喜欢你。
第二次握手：
小红告诉小明：我知道了，我也喜欢你。
此时小红并不确定小明是否收到了告白信，直到
第三次握手：
小明回信：我也知道了，我们在一起吧。此时才真正建立连接。

(DHCP 也是这么个逻辑)

主机A发送位码为syn＝1，随机产生seq number=x的数据包到服务器，主机B由SYN=1知道，A要求建立联机；

主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1)，syn=1，ack=1，随机产生seq=y的包

主机A收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1)，ack=1，主机B收到后确认seq值与ack=1则连接建立成功。

TCP: closing a connection 四次挥手

client, server each close their side of connection

• send TCP segment with FIN bit = 1respond to received FIN with ACK

• on receiving FIN, ACK can be combined with own FIN

simultaneous FIN exchanges can be handled

恋爱之后，小明和小红煲电话粥。依旧将小明当作客户端，小红当作服务器端。小明跟小红说话
第一次挥手：
小明说：我说完了。
第二次挥手：
小红说：好的，我知道了，我还没说完。
小红继续吧啦吧啦，说完之后
第三次挥手：
小红告诉小明：我说完了。
第四次挥手：
小明收到后告诉小红：好的，我知道了。等了2MSL之后小明挂断了。
如果此时小红说完，等了2MSL，小明一直不出声，这个时候就会重新说一次：我说完了。直到收到小明最后的回复，才挂断电话。

Principles of congestion control

congestion:too many sources sending too much data too fast for network to handle

表现为

• lost packets (buffer overflow at routers)

• long delays (queueing in router buffers)

原因（网络自身问题）：

Too much traffic enters router – buffer fills up, this increases delay
Much too much traffic enters router – buffer overfills and causes loss. Packet needs to be retransmitted
If packet is lost after several “hops” then many resources are wasted. (e.g. Packet travels from A to B to C to D then lost at D – it has taken up space at A, B and C unnecessarily)
前面的流量控制是避免「发送方」的数据填满「接收方」的缓存，但是并不知道网络的中发生了什么。一般来说，计算机网络都处在一个共享的环境。因此也有可能会因为其他主机之间的通信使得网络拥堵。TCP 不能忽略网络上发生的事，它被设计成一个无私的协议，当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。那么怎么知道当前网络是否出现了拥塞呢？

其实只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。

goodput（实际吞吐量） – this is the rate at which data reaches the application layer. Different from throughput because of:

• loss

• retransmission

• corrupted packets

rwnd = flow control (not too fast for receiver)

cwnd = congestion control (not too fast for network)

TCP congestion control

congestion window由发送方主动调节

两种控制方式

Slow Start

在TCP建立连接的开始：increase rate exponentially until first loss event

• initially cwnd = 1 MSS

• double cwnd every RTT

• done by incrementing cwnd for every ACK received（收到一个ACK cwnd×2）

AIMD（additive increase multiplicative decrease）

加性增，乘性减

approach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs

• Set cwnd – congestion window to initial value

additive increase : increase cwnd by 1 MSS（一个窗口大小） every RTT until loss detected

multiplicative decrease ：cut cwnd in half after loss

TCP Tahoe和Reno是处理TCP拥塞控制的两种形式（在三次冗余ack上有不同）

TCP RENO:

由于超时所引发的loss ，将cwnd设为1 MSS(重设threshold为上次丢包值的一半)，重新慢启动至ssthresh慢启动门限，再使用AIMD

由3 duplicate ACK引发的loss cwnd减半然后线性增加（AIMD）

TCP Tahoe :

always sets cwnd to 1 (timeout or 3 duplicate acks)

TCP throughput平均吞吐量

TCP Fairness

if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K

TCP比起UDP来说需要在意网络拥塞的状态，而不是像UDP不管不顾的一直发送

application can open multiple parallel connections between two hosts

一个应用通常同时使用多个TCP连接（否则一直建立解除TCP效率太低了）

e.g., link of rate R with

9 existing connections:

• new app asks for 1 TCP, gets rate R/10

• new app asks for 11 TCPs, gets just over R/2

Chapter 2 Transport Layer

提纲

Application layer

1. Application layer

Sockets

Addressing processes

4 different addresses in TCP/IP

Physical address Layer 2

Logical address Layer 3 (32-bit , IPv4 128-bit IPv6)

Port address Layer 4 (16-bit)

**Application-specific address Layer 7 **特定应用地址

application protocol defines

1. types of messages exchanged

2. message syntax

3. message semantics (语义)

4. rules for when and how processes send & respond to messages

open protocols:

proprietary protocols专用（私有）协议:

translation layer

Multiplexing/demultiplexing

Multiplexing (Mux):

Demultipliexing (Demux)

How demultiplexing works

Connectionless demux

Connection-oriented demux

Typical port numbers for applications

UDP: User Datagram Protocol

Simplest usable Internet transport protocol

connectionless:

UDP use:

reliable transfer over UDP: 用udp实现可靠传输的方法

UDP checksum

Principles of reliable data transfer （rdf）

可靠数据传输原理

rdt1.0: reliable transfer over a reliable channel

rdt2.0: channel with bit errors

rdt2.1: sender, handles corrupt ACK/NAKs

rdt2.2: a NAK-free protocol

rdt3.0: channels with errors and loss

Performance of rdt3.0

Pipelined protocols

slide window流程

sender:

reciver

Go-Back-N

sender：

Selective repeat

窗口长度必须小于等于序号空间大小一半

TCP （Transmission Control Protocol）

TCP header

TCP round trip time, timeout

retransmission scenarios

TCP fast retransmit

TCP flow control

MSS and MTU

Nagle’s algorithm

Nagle’s algorithm

Silly Window Syndrome

发送端引起的糊涂窗口综合症

接收端引起的糊涂窗口综合症

Connection Management

TCP 3-way handshake

TCP: closing a connection 四次挥手

Principles of congestion control

TCP congestion control

Slow Start

AIMD（additive increase multiplicative decrease）

TCP Fairness

Application-specific address Layer 7 特定应用地址