面向连接的运输——TCP

TCP简介

特点：连接、握手、点对点、只在传输层。

TCP协议只在端系统中允许，而不在中间的网络元素（路由器和链路层交换机）中运行，所以中间的网络元素不会维持TCP连接状态。事实上，中间路由器对TCP连接完全视而不见，他们看到的是数据报。而不是连接。

TCP提供全双工服务：如果一台主机上的进程A与另一台主机上的进程B存在一条TCP连接，那么应用层数据可以从B流向A，也从A流向B。
TCP连接也总是点对点的，即在单个发送方与单个接收方之间的连接。

TCP连接的组成包括：一台主机上的缓存、变量和与进程连接的套接字，以及另一台主机上的另一组缓存、变量和与进程连接的套接字。在这两台主机之间的网络元素（路由器、交换机和中继器）中，没有为该连接分配任何缓存和变量。

TCP报文段结构

结构

序号

TCP把数据看成一个无结构的、有序的字节流。我们从TCP对序号的使用上可以看出这一点，因为序号是建立在传送的字节流之上，而不是建立在传送的报文段的序列之上。
一个报文段的序号因此是该报文段首字节的字节流编号。

确认号

主机A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号。
因为TCP只确认该流中至第一个丢失字节为止的字节，所以TCP被称为提供累计确认。

可靠数据传输

因特网的网络层服务（IP服务）是不可靠的。IP不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性。

TCP发送方与发送重传有关的3个事件

1.从上层接收数据

TCP从应用程序接收数据，将数据封装在一个报文段中，并把该报文段交给IP。
每一个报文段都包含一个序号，这个序号就是该报文段第一个数据字节的字节流编号。
如果定时器没有为某些其他报文段而运行，则当报文段被传给IP时，TCP就启动该定时器。（定时器与最早的未被确认的报文段相关联）

2.定时器超时

重传具有最小序号但仍未应答的报文段，然后重启定时器。

3.收到ACK

TCP将ACK的值y与它的变量SendBase进行比较。TCP状态变量SendBase是最早未被确认的字节的序号。
TCP采用累计确认，所以收到y确认了字节编号在y之前的所有字节都已经收到。
如果y>SendBase，则该ACK是在确认一个或多个先前未被确认的报文段。因此发送方更新它的SendBase变量。如果当前有未被确认的报文段，TCP还要重新启动定时器。

一些有趣的情况

//书上的标题就是这玩意，我不知道咋起名

TCP实现中做的修改

超时间隔加倍

定时器过期后超时时间间隔，每次TCP重传时都会将下一次的超时间隔设为先前值的两倍。

快速重传

当接收方检测到有报文段丢失，对已经接收到的最后一个按序字节数据进行重复确认，发送冗余ACK。
如果TCP接收方接收到对相同数据的3个冗余ACK，说明在这个已被确认过3次的报文段之后的报文段已经丢失。
一旦收到3个冗余ACK，TCP就执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段。

是回退N步还是选择重传

TCP发送方：仅需维持已发送过但未被确认的字节的最小序号和下一个要发送的字节的序号。
选择确认：它允许TCP发送方有选择地确认失序报文段，而不是累积的确认最后一个正确接收的有序报文段。

如果对报文段n+1的确认报文在报文段n超时之前到达， TCP甚至不会重传报文段n。

TCP连接管理

三次握手

1.SYN报文段
客户端TCP向服务器端的TCP发送一个特殊的TCP报文段。该报文段中不包含应用层数据。
报文段的首部SYN标志位被设为1。这个特殊报文段被称为SYN报文段。
另外，客户会随机选择一个初始序号（client_isn），并将此编号放置于该起始的TCP SYN报文段的序号字段中。
该报文段会被封装在一个IP数据报中，并发送给服务器。
2.SYN ACK报文段
服务器从IP数据报中取出TCP SYN报文段，这个报文段也不包含应用层数据。
为TCP连接分配TCP缓存和变量。
SYN比特被置为1。
该TCP报文段首部的确认号字段被置为client_isn+1。
最后，服务器选择自己的初始序号server_isn，并将其放到TCP报文段首部的序号字段中。
实际上表明了：“我收到了你发起建立连接的SYN分组，该分组带有初始序号client_isn，我同意建立该连接，我自己的初始序号是client_isn+1”
3.
在收到SYNACK报文段，客户也要给该连接分配缓存和变量。
客户将server_isn+1放到TCP报文段首部的确认字段，对服务器的允许连接的报文段进行了确认。
因为该连接已经建立了，所以该SYN比特被置为0.
三次握手的第三个阶段可以在报文段负载中携带客户到服务器的数据。

四次挥手

客户应用进程发出一个关闭连接命令，客户TCP向服务器进程发送一个特殊的TCP报文段，将首部标志位FIN被置为1。
2.
服务器接收到该报文段后，就向发送方回送一个确认报文段。
3.
然后，服务器发送它自己的终止报文段，FIN被置为1.
4.
最后，客户对服务器这个终止报文段进行确认。此时，在两台主机上用于该连接的所有资源都被释放了。

TCP经历的状态

流量控制

目的

消除发送方使接收方缓存溢出的可能性

概括

流量控制是一个速度匹配服务，即发送方的发送速率与接收方的应用程序读取速率相匹配。

方法

让发送方维护一个称为接收窗口的变量来提供流量控制。
接收窗口指示发送方，接收方还有多少可用的缓存空间。
因为TCP是全双工通信，在连接两端的发送方都各自维护一个接收窗口。

定义以下变量：
RcvBuffer:接收缓存的大小
LastByteRead:主机B上的应用进程从缓存读出的数据流的最后一个字节的编号。
LastByteRcvd:从网络中到达的并且已放入主机B接收缓存中的数据流的最后一个字节的编号。
LastByteRcvd-LastByteRead<=RcvBuffer 必须成立，因为TCP不允许已分配的缓存溢出。
rwnd=RcvBuffer-[ LastByteRcvd - LastByteRead ]，可用空间的数量

主机B通过把当前的rwnd值放入它发给主机A的报文段接收窗口字段中，通知主机A他在该连接的缓存中还有多少可用空间。
一开始，rwnd=RcvBuffer。

主机A必须保证，LastByteSent-LastByteAcked<=rwnd。

一个问题

当主机B的接收窗口为0时，主机A继续发送只有一个字节数据的报文段。这些报文段将会被接收方确认。最终缓存将开始清空，并且确认报文里将包含一个非0的rwnd值。

与UDP对比

udp不提供流量控制，缓存溢出将丢失报文段。