沧小海读《图解TCP/IP》笔记——第六章 TCP与UDP

---

总目录在这里~

https://blog.csdn.net/z123canghai/article/details/107855399

---

子目录

6.1 传输层的作用

6.2 UDP

6.3 TCP

---

6.1 传输层的作用

         数据到了传输层，基本上可以确定数据是给本主机的了，当然也有例外，例如（4~7层交换机）。本层的作用就是接收网络层数据解析给对应的应用程序，以及接收应用层数据组装给到网络层。

         这一层主要有两个协议，就是TCP和UDP，前面已经说过，TCP是面向连接的能够进行可靠传输，而UDP就是傻乎乎的上面给啥就发啥，收到什么就给应用层什么，不管不顾。这两种协议满足了不同的需求。而这两种数据类型的区分靠的是协议号。UDP的协议号是17，TCP的是6。

         而数据从传输层到应用层还需要端口号的配合，因为应用软件有很多，数据给谁需要一个地址，这个地址就是端口号。也可以理解为传输层的地址，通过这个地址知道了数据的来处和去向。

 

综上，我们可以知晓，一包数据通过MAC地址、IP地址、协议号、端口号遍可完成一包数据的传输。而IP地址分为目的IP地址和源IP地址，端口号也是分为目标端口号和源端口号。这些都必须确定，否则是无法实现的

---

6.2 UDP

         UDP是user datagram protocol，该协议比较简单，不提供复杂的控制机制，这方面可以与后文的TCP对比发现，利用IP提供面向无连接的通信服务。无法避免网络拥堵、丢包等现象，当然，在应用层可以加写内容进行判断。其数据格式如下

 

         源端口号即发送端端口号，位宽16bit。如果不需要返回数据包，或者说对接收的数据包进行响应，源端口号是可以不设置的。

         目标端口号即接收方的对应的应用程序端口号；

         包长度保存了UDP 部首长度和数据长度之和，是以字节为单位；

---

6.3 TCP

TCP协议传输特点可以说是可靠性高于一切，其他的一切优化升级都是在保证其传输数据可靠的前提下进行。基于此，TCP会通过校验、序列号、确认应答、重发控制、连接管理以及窗口控制等机制解决数据破坏、丢包、重复和分片顺序混乱等问题。

         首先，来看下TCP最基本的传输机制。

         TCP在IP这种无连接的网络上也能实现高可靠性链路，就在主机之间进行数据交换时建立虚拟连接，建立连接的方式就是我们经常说的“三次握手建立连接，四次挥手断开连接”。说“三次握手”似乎给人感觉就是握手三次似的，其中只是需要三个数据包建立连接。一般建立连接两包就够了，即请求与响应，但网络是错综复杂的，在这错综复杂的环境下要考虑诸多因素，例如防止旧的重复连接造成初始化混乱、完成双方初始序列号同步，也避免资源浪费。另外，服务端反馈的数据包含SYN和ACK两个内容，用于确认应答和序列号同步。四次挥手也是，都要求对双方给予请求切断连接的确认应答。

         TCP发送数据是以段的形式进行的，这在前面也有过相关描述。在建立连接的同时就要确定发送数据包的单位，也称之为最大消息长度——MSS（Maximum Segment Size）。之后的通讯数据长度就以双方约定好的长度进行发送，每发送一包数据都会有与之相适应的响应来保证传输的可靠性，当然，也在改基础之上做了优化。

      基本的通讯机制建立了，前辈大佬们又在保证可靠性的前提下进行了优化。

1是窗口控制

         如下图，我们原本想着是如左图所示的传输方式，但大佬们想到了图右的做法，就是“利用窗口控制提高速度”。发一包等一个确认太慢了，所以就想到了以更大的单位进行确认，只要不大于这个单位就一包接着一包的发。例如下图右，这个更大的单元就是窗口，窗口大小就是指无需等待确认应答而可以继续发送数据的最大值，类似于FPGA的FIFO，下图窗口大小就是4个段。

 

具体来看，如下图，白色区域为窗口，窗口内的数据即使没有收到确认应答也可以继续发送，当收到确认应答等候，窗口就会滑动到确认应答的序列号位置。这种机制叫做滑动窗口控制。另外，如果我们连续发了4包，没有收到1001到2001段的确认应答，但收到了3001到4001的确认应答，那么久无需等待1001到2001段的确认应答了。这就涉及到了接下来要说的重发控制。

 

        丢段有两种可能，一是其实数据收到了，但确认应答丢了，二是确实没收到数据。

         对第一种，如下图，通过上述机制可在一定程度上避免，即使部分确认应答丢失也不会触发重发机制。

 

对于第二章，确实数据丢失了，如下图，如果没有收到1001~2000字段的数据，主机B就会不断的发送已接收1~1000的确认应答，以请求1001~2000字段内容，如果连续收到三包同样的确认应答就进行重发，这种机制叫做高速重发控制。

 

 

---

  最后，本书还提到了流控制和拥塞控制两种机制，这也是在其它通信方面会用到的。

         首先来说流控制，其实上文说的窗口控制是由接收端决定的，而且还是一个弹性缓冲区，可大可小。接收端会时不时的给发送端发送一个叫做“窗口探测的数据段”，该数据段仅含有一个字节以获取最新的窗口大小信息。

那为什么要做流控制，因为接收端接收的数据来源可能很多，如果主机A、B再沟通之时来个第三者插入，而且这个第三者还挺吸引人，那么主机B就会减少与A的沟通时间，转而与第三者进行互动，如果这时A还是可劲的给数据，可能会被B忽视，从而触发A的重发机制，B还是丢弃，这样操作网络流量的浪费，所以B会好心的告诉A我在忙，你发慢点，调节下窗口大小。A就明白了，慢慢的发送，如下图所示。

 

         什么是拥塞控制？计算机网络都处于一个共享环境，你发的数据多点，别人就得收敛点，如果现在网络繁忙，你发的多可能就丢失的多。基于此，大佬们设计了一个拥塞控制机制，其实就是慢启动，或者说试探性发送数据，一开始我少发点，看看行情，觉得行情不错我再多发点，然后发现依旧不错，那就再多发点，这样一个逐步调节吞噬网络带宽的过程。大致知道就好，反正FPGA也很少去做TCP协议。

 

---

最后看下TCP的部首格式，这比UDP要复杂的多。

1、源/目标端口号

         这个不多说，和UDP一样

2、序列号（Sequence Number）

3、确认应答（Acknowledgement Number）

4、数据偏移

 

5、保留

6、控制位（Control Flag）

 

 

 

 

 

 

 

 

7、窗口大小（Window Size）

8、校验和

9、紧急指针（Urgent Pointer）

9、选项（Options）