tcp/ip到底是什么？

淡淡的烟草味﹌ 2023-02-17 14:50 9阅读 0赞

### TCP/IP ###

*  TCP/IP
 *   *  三次握手
     *   *  1.client端发送连接请求报文
         *  2.server端接受连接后回复ack报文，并为连接分配资源
         *  3.client接受到ack报文，向server发送ack资源
         *  为什么需要三次握手，而不是两次？
     *  四次挥手
     *   *  1.client发送FIN
         *  2.server发送ACK
         *  3.server发送FIN
         *  4.client发送ACK
         *  为什么要四次？
     *  tcp与udp的区别
     *  可靠传输
     *   *  校验和
         *  确认应答+序列号
         *  超时重传
         *  流量控制
         *   *  滑动窗口
         *  拥塞控制
         *   *  定义
             *  方法
             *   *  慢开始
                 *  拥塞阻塞
                 *  快重传
                 *  快恢复

# TCP/IP #

## 三次握手 ##

![三次握手示意图][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ_size_16_color_FFFFFF_t_70]

### 1.client端发送连接请求报文 ###

*  其首部中同步位SYN（是否同步）被设置为1。另外，客户机会随机选择一个起始序号seq=x
 *  连接请求报文不携带数据，但要消耗一个序号
 *  ACK1或者0和确认号有关；
 *  URG将高级的字节码放到最前面传输，也就是插队传输。
 *  PSH将高级的的数据包直接放前面提交。
 *  RET：TCP出现了错误需要释放连接。

### 2.server端接受连接后回复ack报文，并为连接分配资源 ###

*  SYN和ACK位都被设置为1，确认号字段值为ack=x+1,并且服务器随机产生起始序号seq=y
 *  确认包同样不包含应用层数据

### 3.client接受到ack报文，向server发送ack资源 ###

*  确认位ACK被设置为1，序号段被设置为seq=x+1,确认号字段ack=y+1
 *  该报文段可以携带数据，如果不携带数据则不消耗序号

### 为什么需要三次握手，而不是两次？ ###

TCP是全双工的，所以要确保双方都可以收到消息；

在三次握手之后，A和B都能确定这么一件事： 我说的话，你能听到； 你说的话，我也能听到。

*  全双工：客户端在给服务器端发送信息的同时，服务器端也可以给客户端发送信息
 *  半双工：A可以给B发，B也可以给A发，但是A在给B发的时候，B不能给A发，即不同时
 *  单工：只能A给B发，B不能给A发； 或者是只能B给A发，不能A给B发

假设改为两次握手，client端发送的一个连接请求在服务器滞留了，这个连接请求是无效的，client已经是closed的状态了，而服务器认为client想要建立一个新的连接，于是向client发送确认报文段，而client端是closed状态，无论收到什么报文都会丢弃。而如果是两次握手的话，此时就已经建立连接了。服务器此时会一直等到client端发来数据，这样就浪费掉很多server端的资源。

## 四次挥手 ##

![四次挥手示意图][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ_size_16_color_FFFFFF_t_70_pic_center]

### 1.client发送FIN ###

*  表示已无数据传送，但若server还有数据发送，则先不关闭socket，可继续发送
 *  socket是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用已实现进程在网络中通信
 *  该报文段的结束标志位FIN被设置为1，seq=u,它等于前面已经发送过的数据的最后一个字节的序号加1

### 2.server发送ACK ###

*  表示信息已收到，但我没准备好，请等待我的消息client：FIN-wait状态
 *  确认号是ack=u+1,序号为v,等于它前面已经发送过的数据的最后一个字节序号加1.此时客户机到服务器这个方向的连接就释放了，TCP处于半关闭状态

### 3.server发送FIN ###

*  已传完，可关闭
 *  此时发出FIN=1，确认号ack=u+1,序号seq=w,已经发送过的数据最后一个字节加1。确认为ACK=1

### 4.client发送ACK ###

*  在确认报文段中，确认位ACK=1，序号seq=u+1,确认号ack=w+1
 *  Time-Wait

为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

还可以防止已失效的报文段。客户端在发送最后一个ACK之后，再经过经过2MSL，就可以使本链接持续时间内所产生的所有报文段都从网络中消失。从保证在关闭连接后不会有还在网络中滞留的报文段去骚扰服务器

### 为什么要四次？ ###

根据状态流程图，我们可以看出服务端响应断开连接的请求时，其ACK和FIN包并不是一起发送给客户端的，因为第一次由客户端->服务端的FIN信号表示的是客户端想要断开连接。服务端先给出ACK确认信号，表示已经收到FIN请求，然后当自己也可以结束的时候，再次发送FIN信号，所以需要挥手交互需要四次。

## tcp与udp的区别 ##

*  tcp基于连接（需要先建立连接，且仅有两方），udp基于无连接
    
    面向连接的服务：通信双方进行通信之前，必须先建立连接，在通信过程中，整个连接情况一直都是被实时地监控和管理。当通信结束后，则应释放这个连接
    
    无连接服务：两个实体之间的通信不需要先建立好连接，需要通信的时候，直接将信息发送到”网络”中，让该信息的传递在网上尽力而为地往目的地传送
 *  对系统资源的要求：tcp多，udp少
 *  udp程序结构较为简单，有较好的实时性
 *  tcp是数据流形式，udp是数据报的形式
 *  tcp保证数据正确性，udp可能丢包，tcp保证数据顺序，udp不保证
 *  应用场景不同
    
    tcp：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录
    
    udp：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）

## 可靠传输 ##

### 校验和 ###

*  发送的数据包的二进制相加然后取反，目的是检测数据在传输过程中的任何变化
 *  收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段

### 确认应答+序列号 ###

*  TCP传输时将每个字节的数据都进行了编号
 *  有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据
 *  每次接收方收到数据后，都会对传输方进行确认应答，即发送ACK报文，带有对应的确认序列号

### 超时重传 ###

*  超时以500ms（0.5秒）为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍

### 流量控制 ###

*  防止较快主机致使较慢主机的缓冲区溢出
 *  解决通信两端处理时间不一样的问题。通过实时调整滑窗尺寸的大小(尺寸甚至可以是0)来实现流量控制。接收端主动调整滑窗大小，发送端根据接收端发送的报文调整相应的滑窗。发送端也会定时发送报文向接收端确认滑窗信息，避免接收端发送的相关调整滑窗大小的报文丢失带来的影响。
 *  流量控制协议是可变大小的滑动窗口协议

#### 滑动窗口 ####

窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小，而且接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ_size_16_color_FFFFFF_t_70 1]

*  发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度
 *  如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端
 *  发送窗口大小swnd=min（rwnd，cwnd）。rwnd是接收窗口，cwnd用于拥塞控制

### 拥塞控制 ###

#### 定义 ####

*  防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载
 *  发送方维持一个拥塞窗口cwnd的状态变量，拥塞窗口的大小取决于网络的拥塞程度，并且动态变化，发送方让自己的发送窗口等于拥塞；只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数

#### 方法 ####

##### 慢开始 #####

*  在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值
 *  每经过一个传输轮次，拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT（此时窗口指数级扩大）
    
    传输轮次强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认
    
    为防止拥塞窗口cwnd增长过大引起网络拥塞，设置慢开始门限ssthresh状态变量；
    
    当 cwnd < ssthresh 时，使用上述的慢开始算法。  
    当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。  
    当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ_size_16_color_FFFFFF_t_70_pic_center 1]

##### 拥塞阻塞 #####

*  让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多
 *  “拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。“拥塞避免”是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞

##### 快重传 #####

*  要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认

![快重传][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ_size_16_color_FFFFFF_t_70_pic_center 2]

*  假定接收方没有收到M3但接着收到了M4。显然，接收方不能确认M4，因为M4是收到的失序报文段。根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认
 *  按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了接收方的四个对M2的确认，其中后三个都是重复确认
 *  发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必继续等待M3设置的重传计时器到期

##### 快恢复 #####

并不像慢开始那样子，将cwnd设置为1 ，而是将cwnd设置为新的ssthresh值；

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200614163948365.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200614165843586.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200614174451132.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20200614180034267.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/2020061419012962.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODcwMDc2OQ==,size_16,color_FFFFFF,t_70#pic_center