全称
传输控制协议，Transmission Control Protocol
特点
- T C P提供一种面向连接的、可靠的字节流服务
- 面向连接意味着两个使用T C P的应用（通常是一个客户和一个服务器，C/S）在彼此交换数据之前必须先建立一个T C P连接
- 一个T C P连接中，仅有两方进行彼此通信
可靠性（检错、应答确认、数据错误处理）
- 应用数据被分割成T C P认为最适合发送的数据块
- 当T C P发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段
- 当T C P收到发自T C P连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒
- T C P将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错， T C P将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）
- 如果必要， T C P将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层（IP层数据数据失序的影响）
- T C P的接收端必须丢弃重复的数据（IP层数据重复的影响）
- T C P还能提供流量控制。T C P连接的每一方都有固定大小的缓冲空间，C P的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出
字节流服务（ byte stream service）
两个应用程序通过T C P连接交换8 bit字节构成的字节流。T C P不在字节流中插入记录标识符
TCP结构
封装
首部，一般是20字节
-
唯一的TCP连接，每个T C P段都包含源端和目的端的端口号，用于寻找发端和收端应用进程。这两个值加上I P首部中的源端I P地址和目的端I P地址唯一确定一个T C P连接。（有时，一个I P地址和一个端口号也称为一个插口（ s o c k e t））
-
序号用来标识从T C P发端向T C P收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节（序号是32 bit的无符号数，序号到达23 2－1后又从0开始）
-
U R G 紧急指针（ u rgent pointer）有效（见2 0 . 8节）。
A C K 确认序号有效。
P S H 接收方应该尽快将这个报文段交给应用层。
R S T 重建连接。
S Y N 同步序号用来发起一个连接。这个标志和下一个标志将在第1 8章介绍。
F I N 发端完成发送任务。
-
T C P的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小是一个16 bit字段，因而窗口大小最大为6 5 5 3 5字节
-
检验和覆盖了整个的T C P报文段： T C P首部和T C P数据。这是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证
TCP连接的建立与终止
- 传说中的三次握手（建立）
-
请求端（通常称为客户）发送一个S Y N段指明客户打算连接的服务器的端口，以及初始序号（I S N，在这个例子中为1 4 1 5 5 3 1 5 2 1）。这个S Y N段为报文段1。
-
服务器发回包含服务器的初始序号的S Y N报文段（报文段2）作为应答。同时，将确认序号设置为客户的I S N加1以对客户的S Y N报文段进行确认。一个S Y N将占用一个序号。
-
客户必须将确认序号设置为服务器的I S N加1以对服务器的S Y N报文段进行确认（报文段3）。
三次握手
- 传说中的四次握手（终止）
？为什么多了一次，不对称？
原因是，由T C P的半关闭（h a l f - c l o s e）造成的，本来是全双工通信（两边都能发送和接收），而进行FIN发送（接收到这个表示没有数据了）
半关闭：T C P提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力
四次握手
TCP连接超时
所谓超时，得有个参考时间吧，当然也得有个计时器件！
一般新连接最长请求时长是75秒
定时器
TCP半关闭
作用就是，"我已经完成了数据传送，因此发送一个文件结束（ F I N）给另一端，但我还想接收另一端发来的数据，直到它给我发来文件结束（F I N）"
半关闭
握手的状态来自那里？
状态变迁图
打开和关闭
TCP数据流
组成：块数据（用户数据） + 交互数据
交互数据（发送一个字符为例）
- 交互数据总是以小于最大报文段长度的分组发送
交互数据小例
- 经受的时延确认
- 机理：通常T C P在接收到数据时并不立即发送A C K；相反，它推迟发送，以便将A C K与需要沿该方向发送的数据一起发送（有时称这种现象为数据捎带A C K）。绝大多数实现采用的时延为200 ms，也就是说，T C P将以最大200 ms 的时延等待是否有数据一起发送。
-
目的：减少报文段的数目
经受时延
- 用于这个处理的算法：N a g l e算法（广域网环境下）
- 要求一个T C P连接上最多只能有一个未被确认的未完成的小分组，在该分组的确认到达之前不能发送其他的小分组。相反， T C P收集这些少量的分组，并在确认到来时以一个分组的方式发出去。
- 该算法的优越之处在于它是自适应的：确认到达得越快，数据也就发
送得越快
块数据
- 使用的控制协议：滑动窗口协议的另一种形式的流量控制方法。
- 允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输
滑动窗口协议
- 窗口的变化（协议）
变化
-
称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
-
当窗口右边沿向右移动时将允许发送更多的数据，我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了T C P的接收缓存时。
-
当右边沿向左移动时，我们称之为窗口收缩。Host Requirements RFC强烈建议不要使用这种方式。但T C P必须能够在某一端产生这种情况时进行处理。
-
变化的小例
窗口协议数据处理变化过程
- 发送方不必发送一个全窗口大小的数据
- 来自接收方的一个报文段确认数据并把窗口向右边滑动。这是因为窗口的大小是相对于确认序号
- 正如从报文段7到报文段8中变化的那样，窗口的大小可以减小，但是窗口的右边沿却不能够向左移动
- 接收方在发送一个A C K前不必等待窗口被填满
......
网友评论