从0开始http-1-TCP连接过程及常见问题

关注公众号获取更多好文
golang技术实验室

TCP详解

来回顾一下上一章节的内容

TCP/IP协议的通信过程其实就是对应着的数据入栈和出栈的过程，数据发送方每层不断的封装首部和尾部，添加信息，出栈的过程，数据接收方每层不断的拆除首部和尾部，等到最终的数据

以上的以太网首部，更准确应该是MAC头

这一章我们来详细讲TCP

1、和UDP区别

既然讲到TCP，那么自然少不了它的好兄弟UDP，我们先来看下他们呢的区别

面向报文和面向字节流区别

面向报文的传输方式是应用层给UDP多长的报文，UDP就照样转发，即一次发送一个报文，因此应用程序必须选择合适大小的报文，若报文太长，则需要IP层分片降低效率

面向字节流，虽然应用程序和TCP的监护是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流，TCP有一个缓冲，当应用程序传递的数据块太长，TCP就可以把它划分的短一些再传输。

全双工

二台通讯设备之间，允许有双向的资料传输。udp在两台端设备间通信，但与tcp不同的是，udp需要两次连接。也就是说，每一次连接都是单向传输，所以说udp更偏向单工。

tcp不同，一次连接中，双方都可以发送数据，所以是典型的全双工。

2、DNS

DNS属于应用层

运行在用户主机上的某些应用程序需要将主机名转换为IP地址

DNS既有TCP的使用，也有UDP的使用

​ 区域传输的时候使用的是TCP，其他时候是UDP

​ 区域传输：dns的规范规bai定了2种类型的dns服务器，一个叫主dns服务器，一个叫辅助dns服务器。在一个区中主dns服务器从自己本机的数据文件中读取该区的dns数据信息，而辅助dns服务器则从区的权威dns服务器中读取该区的dns数据信息。当一个辅助dns服务器启动时，它需要与主dns服务器通信，并加载数据信息，这就叫做区传送（zone transfer）

3、TCP头信息

头部最少占20字节

**4位头部长度：**标识该tcp头部有多少个32bit字（4字节）因为4位最大能表示15，所以tcp头部最长是60字节

• URG标志，表示紧急指针是否有效
• ACK标志，表示确认号是否有效。称携带ACK标志的tcp报文段位确认报文段
• PSH标志，提示接收端应用程序应该立即从tcp接受缓冲区中读走数据，为接受后续数据腾出空间（如果应用程序不将接收的数据读走，它们就会一直停留在tcp缓冲区中）
• RST标志，表示要求对方重新建立连接。携带RST标志的tcp报文段为复位报文段。
• SYN标志，表示请求建立一个连接。携带SYN标志的tcp报文段为同步报文段。
• FIN标志，表示通知对方本端要关闭连接了。携带FIN标志的tcp报文段为结束报文段。

TCP关注的几个问题

• 顺序问题
• 丢包问题
• 连接维护
• 流量控制
• 拥塞控制
• 粘包问题

4、TCP的连接建立

1. 一开始双方都处于CLOSE状态
2. 客户端发送SYN（表示请求建立连接）seq=x（系列号）给服务端，然后进入SYN_WAIT等待连接建立状态
3. 服务端收到回复SYN，seq=x+1，ack=y，进入SYN_RECV(连接等待接收状态)
4. 客服端收到SYN和ACK，然发送ACK的ACK之，后回复ACK=y+1 seq=x+1，后处于ESTABLISHED状态
5. 服务端收到ACK的ACK进入ESTABLEISHED状态
6. 客户端和服务端建立连接

以上为连接建立过程

1、为什么需要三次握手？

为了防止已失效的连接请求报文突然又传到服务器，建立连接，造成服务端资源浪费

具体例子：在有网络延迟的情况下，客户端发送一个请求，在网络中延迟了，到了超时时间后，客户端任务失败，再次发送一个连接请求，这次正常到达服务端，随后，上次那个延迟的连接报文也到达了，如果没有三次握手，那么每来一个请求就建立一次连接，极大的浪费了服务端的资源，而有了三次握手，服务端收到一个请求，就会问客户端这是你的请求吗，客户端回答这个请求已经被抛弃了，然后服务端拒绝这个请求

2、包的序号为什么不能从1连续的

为了防止已失效的连接请求数据段突然又传到服务器，造成数据错误

具体例子：客户端发送数据包1、2、3，但是3出了问题迷路了，1、2到达，服务端确认数据，客户端收到重新传3，此时3的数据发生变化，但是恰巧之前的那个3到达了，造成数据不是想要传输的

所以数据段的序号设置适合时间变化有关的，可以看成是一个32位的计数器,每4微妙加1,如果重复,大概需要4个小时,那个绕路的包会在TTL时间之后消失

3、 传输包顺序问题

seq由计算机和时间生成的32位的随机序列号

ack：确认序列号，值为seq+1

1. 客户端每次发送数据，TCP就给每个数据包分配一个序列号（seq=x），并且在一个特定的时间内等待服务器对分配的这个序列号进行确认（ack=x+1）
2. 如果客户端在一个特定时间内没有收到服务端的确认，则客户端会重传次数据包

4、 丢包问题

A发送分组M1，发送完就等待B的确认，B收到了就会箱A发送确认，A收到确认后在发送分组M2，以此类推

5、可靠传输工作原理

出现差错怎么办？

1、 数据包传输丢失或者数据包错误

• 分组在传入的过程中，B在接收M1检测的时候出现问题，就丢弃，什么也不做，（不通知A收到有差错的包），因为分组有可能在传输过程中出问题，A只要一段时间没收到确认，就会重传，这就是==超时重传==
• 要实现超时重传，就要在每次发包之后设置一个超时计时器，如果在设定内没收到，就重传，否则撤销定时器
• 此处注意的三个细节
  1. A在发送完分组M1之后要保存其副本，防止超时重传
  2. 分组和确认分组都需要编号，编号是32位置的计数器和时间结合的序列，应答的是序列号+1的回复
  3. 超时定时器的设定要合理，防止时间太长，造成浪费，也应避免时间太短而造成不必要的重传

2、 确认丢失和确认迟到

• B向A发送的确认包丢失，A在超时计时器之后又收到这个分组M1

  • B不想上层交付M1
  • B向A发送确认，不能认为发送过就不再发送，因为A之所以重传，可能就是在超时时间内没收到确认

• B向A发送确认包迟到，A收到重复的确认包

  • A收到重复的就丢弃，B仍然后接收到重复的M1，同样丢弃，在重传确认分组

基于上面的确认和重传机制，*保证在不可靠的传输网络上实现可靠的通信

像上述的这种可靠的传输协议常称为自动重传请求ARQ意思是重传的请求是自动的。接受方不需要请求发送方重传某个出错的分组。

如何提高效率

流水线传输就是发送方可连续发送多个分组，不必每发送完一个分组就暂停等待对方的确认，这样可使信道上一只有数据不断的传送，更好的提高信道的利用率

流水线的传输就要用到ARQ协议和滑动窗口协议

连续ARQ协议

a表示发送方维持的发送窗口，位于发送窗口内的5个分组都可以连续发送出去，而不需要等待对方的确认

连续ARQ协议规定，发送方每收到一个确认，就把滑动窗口向前移动一个分组的位置，，图中下面就是收到第1个分组的确认将发送串口移动一个分组的位置
而接收方一般采用累计确认的方式，也就是说，接收方不必对收到的分组逐个确认，而是在收到几个分组之后，对按序达到的最后一个分组发送确认，这就表示到这个分组为止的所有分组都已经正确收到

累计确认有优点也有缺点，优点：容易实现，即使确认丢失也不必重传，缺点：不能向发送方即使的反映接收方已经收到的所有分组的信息
例如分组中的发送了前5个分组，而中间的第3个分组丢失了，这时接收方只能对前两个分组发送确认，发送方无法得知后面三个分组的下落，然后重传，—go-back-N，可见当通信质量不好的时候，连续ARQ会带来很多负面影响