计算机网络——运输层

目的是总结运输层中两个协议的相关内容（重点TCP）
下面网站是别人的计算机网络知识点总结
https://github.com/Snailclimb/JavaGuide/blob/master/计算机网络与数据通信/计算机网络.md

协议体系结构

OSI：七层协议，从上到下依次是应用层，表示层，会话层，运输层，网络层，数据链路层，物理层；
TCP/IP：四层协议，从上到下依次是应用层，运输层，网络层，网络接口层

运输层概述

简单理解：网络层通过ip找到目标主机，运输层实现应用进程间的数据传输。
运输层应具有复用：发送方：不同的应用进程都可以使用运输层协议传送数据；
分用：接受方：能将报文段交付给正确的应用进程。

运输层的两个协议

UDP：用户数据报协议
TCP：传输控制协议

UDP

UDP协议特点

• 无连接
• 尽最大努力交付：不可靠，
• 面向报文：即不对应用进程传来的数据进行切割；
• 没有拥塞控制：一个应用场景：实时视频会议（拥塞控制会降低源主机发送速率；实时视频允许部分数据丢失）
• 等等

UDP首部格式

包含：源端口，目的端口，长度（=首部长度+数据报长度），检验和，共8个字节
检验和的计算：二进制反码

TCP

TCP协议特点

• 面向连接
• 提供可靠交付的服务
• 提供全双工通信：即每个应用进程在同一时刻既可以是发送方，又可以是接收方
• 面向字节流
• 每一条TCP连接只能有两个端点

端点： 运输层提供端到端的通信，其中端的概念，即是套接字：ip:端口号

传输控制协议TCP概述

停止等待协议

特点：每发送一个分组就停止，等待对方的确认。
缺点：信道利用率非常低

连续ARQ协议

特点：滑动窗口内的数据都可发出，无需等待对方确认；
累积确认：接收方对按序到达的最后一个分组发送确认，表示到这个分组为止的所有分组都已正确收到。

TCP首部格式

首部长度： 20字节+选项部分长度，最大不超过60字节
源端口；目的端口；序号（本次发送的报文段中的第一个字节的序号）；确认号（接收端已按序接受到字节，期待发送端下一次发送的字节序号）；数据便宜（TCP首部长度）；保留；
URG：
ACK：
PSH：
RST：
SYN：
FIN：
窗口：接收方能够接受的字节长度；
检验和；紧急指针（紧急数据的长度）；选项；填充

TCP可靠传输的实现

以字节为单位的滑动窗口

超时重传时间选择

确定超时重传的时间。

选择确认SACK

服务器端未按序收到报文段，实现只重传缺少数据；

TCP的流量控制

滑动窗口

传输效率

发送报文段的时机；

TCP的拥塞控制

拥塞原因：对资源的需求的总和 > 可用资源
四个拥塞控制方法

慢开始

拥塞避免

快重传

快恢复

随即早期检测RED

避免全局同步；

TCP的运输链接管理

运输链接有三个阶段：连接建立，数据传送和连接释放。

连接建立

三次握手

服务进程先创建TCB，处理LISTEN状态；
三个过程描述：

• 客户进程创建传输控制模块TCB，向服务进程发送连接请求报文段：SYN = 1 seq = x
  SYN报文段不携带信息，消耗一个序号；
  之后客户进程处于SYN-SENT状态
• 服务进程收到后，如果同意建立连接，向客户进程确认：SYN = 1, ACK = 1, ack = x + 1, seq = y
  不携带信息，同样消耗一个序号；
  之后服务进程处于 SYN-RCVD状态（接受 received）
• 客户进程收到确认后，再向服务进程给出确认：ACK = 1, ack = y + 1, seq = x + 1
  可以不包含信息，如果不包含，则客户进程发送的下一个数据报文段的序号还是x+1
  之后客户进程处于ESTABLISHED状态
  服务进程接收到该确认后，也进入ESTABLISHED状态。

为什么A（客户进程）还要发送一次确认呢？
防止已失效的连接请求报文段突然又传送到了B（服务进程），因而产生错误。
解释：
A开始发送了一个连接请求报文段m，但该报文段迷失在了网络中（没有丢失，只是卡在了某个地方，产生已失效的连接请求报文段）；于是A又发了一个连接请求报文段n，成功建立了连接L1。在L1连接完成数据传输，并释放后，见了鬼了，B又收到了连接请求报文段m，B发出同意建立连接的报文（B也奇怪，不是刚通信完么）。这是如果没有第三步的A的确认，B发送请求后，连接就建立了；而此时A发现自己没有发出建立连接的请求，因此不予理睬B。（B哭唧唧）；而B认为连接已建立，一直等待A发送数据，浪费资源。（来自计算机网络——谢希仁 第6版）
而由于需要A的第三步的确认，A不会向B发送数据；B收不到确认，知道A并没有建立连接。

释放链接

四次挥手

开始进程A和进程B都处于ESTABLISHED状态，现在A主动提出管理连接。
四个过程解释：

• A进程发送连接释放报文段，停止发送数据：FIN = 1, seq = u
  FIN报文段即使不携带数据，也消耗一个序号；
  之后A处于FIN-WAIT-1 状态
• B发出确认： ACK = 1 , ack = u + 1, seq = v
  之后B处于CLOSED-WAIT状态
  A收到B的确认后，进入FIN-WAIT- 2状态，等待B发出连接释放报文段
• B发出连接释放报文段：FIN = 1, seq = w, ack = u + 1
  之后B处于LAST-ACK状态
• A收到B的连接释放报文后，发出确认：ACK = 1 , ack = w + 1, seq = u + 1
  之后A处于TIME-WAIT状态。A经过2个MSL（最长报文段寿命）后，才进入CLOSED状态
  B收到A的确认后，进入CLOSED状态

为啥A在TIME-WAIT状态必须等待2MSL时间呢？

• 为了保证A发送的最后一个ACK报文段能够到达B；最后A发送的ACK是有可能丢失的，这样B由于收不到对FIN-ACK的确认，就会重传，此时A在这2MSL中就可以接受到重传的报文段，并对该报文段再次发出确认，并重新开始2MSL计时。
  但如果A不等待2MSL，直接断开连接，由于ACK的可能丢失，B就收不到确认，而无法正确进入CLOSED状态。
• 防止“已失效的连接请求报文段”出现在本连接中。在2MSL中，本链接持续的时间内产生的所有报文段都在网络中消失，这样在下一个连接中就不会出现这种旧的连接请求报文段。

保活计时器：
客户端在于服务器建立TCP连接后，如果客户端突发意外，为避免服务器端无限制等待，服务器端采用保活计时器；服务器端每收到客户端的数据后，就重置保活计时器；若超出时间限制未收到数据，就像客户端发送探测报文段；若一连发送十个都没有客户端响应，服务器端就关闭连接。

面试怎么问

以下总结运输层面试可能会问的问题；
问题与答法均来自：
https://github.com/Snailclimb/JavaGuide/blob/master/计算机网络与数据通信/计算机网络.md#二-tcp-三次握手和四次挥手面试常客
TCP 三次握手和四次挥手
TCP、UDP 协议的区别
TCP 协议如何保证可靠传输
在浏览器中输入url地址 ->> 显示主页的过程（面试常客）