UDP： User Datagram Protocol 用户数据报协议

TCP： Transmission Control Protocol 传输控制协议

同时这里指的连接是指逻辑连接，而不是物理连接。

tcp必须三次握手，才能建立可靠连接，也就是只支持一对一的通信。

应用层报文传下来之后或者交付上面，都是保留报文的边界。udp是面向报文的。

tcp将应用进程发送下来的数据块仅仅看做是一连串的字节流。

tcp并不知道字节流的含义，仅仅进行编号。

然后根据策略进行发送。 接收方接收到之后取出数据载荷缓存。

tcp是面向字节流的，这就是tcp可靠传输、流量控制、拥塞控制的核心部分。

实际网络中，tcp的两端是全双工的通信。实际当中，tcp报文包含上千个字节很常见。

使用于IP电话、视频会议等实时的应用。

但对于tcp，尽管网际层提供的是无连接不可靠，也就是说IP数据报产生丢失或者误码，但只要运输层是tcp，那么就是可靠的。

可以理解为，基于tcp的话，不会出现传输错误（误码、丢失、乱序、重复），因为是连接的是可靠的信道。

TCP流量控制

A给B发送数据，B告诉A他的窗口是400字节，那么A就会把自己的滑动窗口也设置为400；

seq就是首部的 序号字段。

这里ACK是TCP的首部中的标志位，取值为1表示这是一个TCP确认报文段。

小写ack是确认号字段，表示序号201前的数据已经全部正确接收了，现在希望收到201之后的数据。

rwnd是首部报文中的窗口字段。取值300表示自己的接受窗口为300了。

主机A接收之后，移动自己的窗口，（发送的就去掉了），同时A也将自己的发送窗口改为300。同时A可以对1-200删掉。而且是先发送301的，因为需要等待发送200时候的超时重传。

最后可以将100-600都删掉了。

当b的接收缓存又有空间了，b会通知A可以继续发了。但是。

为了解决这个问题，tcp为每一个连接设立了一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，如果超时，就发一个零窗口探测报文（只有一个字节的数据），对方在确认这个探测报文段时，给出自己现在的接收窗口值。如果接收窗口仍然是0，那么收到这个报文段的一方就重新启动持续计时器。

拥塞控制

类似堵车堵死车的概念。

TCP的拥塞控制的四种方法：

慢开始、 拥塞避免、 快重传、 快恢复

慢开始

往返时间并非恒定的时间。

拥塞窗口值是几，就能发送几个报文段。

这个时候已经是慢开始门限值了，所以这个时候采用拥塞避免算法。

每次都是线性加1.

并且重新开始cwnd为1开始传输。

慢开始：一开始向网络注入的报文段比较少，并不是指拥塞窗口cwnd增长速度慢。

拥塞避免并非能够完全避免拥塞，而是在拥塞避免阶段将拥塞窗口控制为线性增长，使得网络比较不容易出现拥塞。

快重传算法

快恢复算法

超时重传时间的选择

所以。

TCP下层是复杂的物联网通信，可能每个IP数据报的转发路由还不同，会造成数据报文段的RTT是不一样的。

如果RTTS都不正确了。那么RTO肯定不正确了的。

TCP可靠传输的实现

为了简单起见，下面的过程假定不出现网络拥塞。

现在将31-41的数据封装在几个不同的报文段中发送出去。

接收方只能按照接收到的按序到达数据的最高序号进行确认。因此，发出的确认报文仍然是31号。

发送方收到之后，知道31号丢失了。但是这是第一次接收到确认的报文，不会引起该数据的快重传。

假设现在装有31的数据报文段到了接收方，那么接收方会接收该报文段，并且将31-33存入接收缓存，然后将31-33交付给应用进程，然后给发送发送端发送确认报文，（这个时候滑动窗口已经向前滑动了）。

发送缓存中删除31-33,（收到了确认）

然后发送方将 42-53发出去，但是此时是不知道34-36是没有成功发送的，因为没有接收到接收方发来确认的报文。

如果重传计时器超时，就会重传发送窗口内已经发送的数据，并且重新启动重传计时器。