网络编程基础回顾

计算机网络（5）：运输层

OSI 模型与 TCP/IP 协议

在这里插入图片描述

OSI七层协议模型 (open system interconnection)

应用层：为应用数据提供服务
表示层：数据格式转化，数据加密
会话层：建立、维护和管理会话
传输层：建立、维护和管理端到端的链接，控制数据传输的方式
网络层：数据传输线路选择，IP地址及路由选择
数据链路层：物理通路的发送和数据包的划分，附加Mac地址到数据包
物理层：01比特流的转换

数据传输由顶向下，下层为上层提供服务

TCP/IP四层协议模型

应用层：负责处理特定的应用程序细节，如ftp,http ,smtp,ssh 等；
运输层：主要为两台主机上的应用提供端到端的通信，如TCP，UDP。
网络层（互联网层）：处理分组在网络中的活动，比如分组的选路。
链路层（数据链路层/网络接口层）：包括操作系统中的设备驱动程序、计算机中对应的网络接口卡，01比特流的转换

协议封装

下层协议通过封装为上层协议提供服务。
应用程序数据在发送到物理网络上之前，将沿着协议栈从上往下依次传递。每层协议都将在上层数据的基础上加上自己的头部信息（有时也包括尾部信息），以实现该层的功能。
在这里插入图片描述

TCP 协议头部

在这里插入图片描述

源端口号和目的端口号：再加上IP首部的源IP地址和目的IP地址可以唯一确定一个TCP连接
数据序号：表示在这个报文段中的第一个数据字节序号
确认序号：仅当ACK标志为1时有效。确认号表示期望收到的下一个字节的序号
偏移：就是头部长度，有4位，跟 IP 头部一样，以4字节为单位。最大是60个字节
保留位：6位，必须为0
6个标志位：
URG-紧急指针有效；
ACK-确认序号有效；
PSH-接收方应尽快将这个报文交给应用层；
RST-连接重置；
SYN-同步序号用来发起一个连接；
FIN-终止一个连接；
窗口字段：16位，代表的是窗口的字节容量，也就是TCP的标准窗口最大为2^16 - 1 = 65535个字节；
校验和：源机器基于数据内容计算一个数值，收信息机要与源机器数值结果完全一样，从而证明数据的有效性。检验和覆盖了整个的TCP报文段：这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证的；
紧急指针：是一个正偏移量，与序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式；
选项与填充（必须为4字节整数倍，不够补0）：最常见的可选字段的最长报文大小 MSS（Maximum Segment Size），每个连接方通常都在一个报文段中指明这个选项。它指明本端所能接收的最大长度的报文段。
该选项如果不设置，默认为 536（20+20+536=576字节的IP数据报）

三次握手

在这里插入图片描述
1.客户端向服务器发送 SYN：
客户端发起连接请求，发送一个TCP报文段，其中包含SYN（同步）标志，并选择一个初始序列号Seq=X（X一般为1）。随后客户端进入SYN-SENT 阶段。
这个报文段不包含数据，但在TCP首部中有SYN标志位。
2.服务器收到SYN并发送ACK + SYN：
服务器收到客户端的SYN后，结束 LISTEN 阶段，回应一个确认（ACK）标志，确认收到了客户端的请求，同时也发送一个SYN标志。
服务器选择一个自己的初始序列号（Seq=y）。随后服务器端进入SYN-RCVD 阶段。
3.客户端收到ACK + SYN：
客户端收到服务器的确认和SYN后，结束 SYN-SENT 阶段，回应一个ACK标志（Ack=y+1），确认收到服务器的响应。随后客户端进入ESTABLISHED阶段。
从此时开始，数据传输的双向连接建立完成，可以开始进行数据传输。

在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续"握手"，以此确保了"三次握手"的顺利完成。

滑动窗口

维持发送方/接收方缓冲区，缓冲区是用来解决网络之间数据不可靠的问题，例如丢包，重复包，出错，乱序。在TCP协议中，发送方和接受方通过各自维护自己的缓冲区。通过商定包的重传机制等一系列操作，来解决不可靠的问题。

正常情况：
在这里插入图片描述

在这里插入图片描述
4号包对方已经被接收到，所以被涂成了灰色。“窗口”就往右移一格，这里只要保证“窗口”是7格的。我们就把11号包读进了我们的缓存。进入了“待发送”的状态。8、9号包已经变成了黄色，表示已经发送出去了。接下来的操作就是一样的了，确认包后，窗口往后移继续将未发送的包读进缓存，把“待发送“状态的包变为”已发送“。

丢包情况：
在这里插入图片描述
有可能我们包发过去，对方的Ack丢了。也有可能我们的包并没有发送过去。从发送方角度看就是我们没有收到Ack。

一般情况：一直在等Ack。如果一直等不到的话，我们也会把读进缓存的待发送的包也一起发过去。但是，这个时候我们的窗口已经发满了。所以并不能把12号包读进来，而是始终在等待5号包的Ack。

如果我们这个Ack始终不来怎么办呢？采用超时重传机制解决:
发送端每发送一个报文段，就启动一个定时器并等待确认信息；接收端成功接收新数据后返回确认信息。若在定时器超时前数据未能被确认，TCP就认为报文段中的数据已丢失或损坏，需要对报文段中的数据重新组织和重传。(重传超时时间: RTO)
在这里插入图片描述

四次挥手

在这里插入图片描述

客户端发送断开 TCP 连接请求的报文，其中报文中包含 seq 序列号，是由发送端随机生成的，并且还将报文中的 FIN 字段置为1 ，表示需要断开TCP连接。（FIN=1，seq=u，u由客户端随机生成）
服务端会回复客户端发送的 TCP 断开请求报文，其包含 seq 序列号，是由回复端随机生成的，而且会产生 ACK 字段，ACK 字段数值是在客户端发过来的 seq 序列号基础上加 1进行回复，以便客户端收到信息时，知晓自己的 TCP 断开请求已经得到验证。（ACK=1，FIN=1，ack=u+1，seq=v，v由服务端随机生成）
服务端在回复完客户端的 TCP 断开请求后，不会马上进行TCP连接的断开，服务端会先确保断开前，所有传输到A的数据是否已经传输完毕，一旦 确认传输数据完毕，就会将回复报文的 FIN 字段置1， 并且产生随机 seq 序列号。（ACK=1，FIN=1，ack=u+1，seq=w，w由服务端随机生成）
客户端收到服务端的TCP断开请求后，会回复服务端的断开请求，包含随机生成的 seq 字段和ACK字段，ACK字段会在服务端的TCP断开请求的seq基础上加1，从而完成服务端请求的验证回复。（ACK=1，FIN=1，ack=w+1，seq=u+1）