网络基础（中）

网络基础（中）

1.序列化

• 序列化：将程序中的数据结构转化成为二进制序列
• 数据结构：内存如果是连续的，直接就可发送，例如：结构体
  内存如果不是连续的，序列化就是将不同的内存组合起来，放到一块的空间当中，发送出去，例如：链表多个节点
• 反序列化：将二进制序列转化为数据结构

2.HTTP协议-应用层协议-超文本传输协议

1.概述

• HTTP是无连接、无状态的工作在应用层的协议
• 无连接：http协议本身是没有维护连接信息的，http的数据会交给网络协议栈传输层的TCP协议，而TCP是面向连接的
• 无状态：http本身不对请求和1相应之间的通信状态进行保存，也就是说http协议对发送过的请求和响应都不做持久化处理

2.http协议的url解释

• A.使用http:或https:等协议方案名获取访问资源时要指定协议类型。不区分字母大小写，最后附一个冒号（😃
• b.登录信息（认证）指定用户名和密码作为从服务器端获取资源时必要的登录信息（身份认证）。此项是可选项。
• c.服务器地址，必须指定待访问的服务器地址。地址可以是类似hackr. jp 这种DNS可解析的名称，或192.168.1.1这类IPv4地址名，还可以是[0:0:0:0:0:0:0:1]这样用方括号括起来的IPv6地址名。
• d.服务器端口号指定服务器连接的网络端口号。此项也是可选项，若用户省略则自动使用默认端口号。
• e.带层次的文件路径指定服务器上的文件路径来定位特指的资源。。f.查询字符串针对已指定的文件路径内的资源，可以使用查询字符串传入任意参数。此项可选。
• g.片段标识符使用片段标识符通常可标记出已获取资源中的子资源(文档内的某个位置》。该项也为可选项。

3.http协议的数据流

4.http协议的格式

请求：

• 请求首行：……\r\n 包含了请求方法、请求资源、协议版本
• 请求体：key:value\r\n 包含了属性信息
• 空行：\r\n
• 请求正文

响应:

• 响应首行：协议版本、状态码、状态码解释
• 响应体：属性信息
• 空行
• 响应正文：返回的数据

5.http协议版本

http协议目前有4个版本，其中1.0和1.1版本在互联网上被广泛使用，2.0版本目前应用很少，是下一代的http协议:

http/0.9版本：1991年，原型版本，功能简陋，只有一个命令GET，服务器只能回应HTML格式字符串，该版本已过时。

http/1.0版本：1996年5月，支持cache、MIME、method等,任何格式的内容都可以发送,除了GET命令，还引入了POST命令和HEAD命令。

http/1.1版本：1997年1月，默认建立持久连接，并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求，以便降低线路负载，提高传输速度,新增方法：PUT、 PATCH、 OPTIONS、 DELETE。

http/2 版本：2015年5月作为互联网标准正式发布，头部信息和数据体都是二进制，引入头信息压缩机制等

http1.X 存在的问题问题：

• 传输数据是明文，客户端和服务器端都无法验证对方的身份，无法保证数据的安全性
• header头部数据太长。
• 每次传输还是要重新连接。
• server不能主动push。
• 1.1版本允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应，可能会造成Head-of-line blocking（队头阻塞）的问题。

6.http协议请求方法

7.http协议响应状态码

8.请求/响应头部字段

• Host:指定请求的服务器的域名和端口号
• Accept：指定客户端能够接收的内容类型
• Accept-Language:浏览器可接受的语言
• Accept-Charset:浏览器可以接受的字符集编码
• Connection:表示是否需要持久连接（http1.1默认进行持久连接）
• Content-Type:请求的与实体对应的MIME信息
• Content-Type:请求的内容长度
• Referer:先前网页的地址，即来路
• Cookie:用于在客户端存储少量信息，通常用于实现会话功能
• Location:搭配3XX状态码使用，告诉客户端接下来去哪里访问

9.Cookie和Session

• Cookie :浏览器保存的信息，一般是客户端的一些不敏感的信息。cookie数据的来源自服务端，在浏览器保存。当下次在请求服务端的某个资源的时候，会携带上
• Session: session数据保存在服务器端，一般描述当前会话信息（例如:浏览器的信息，浏览器访问到那个页面等等)

3.UDP协议

1.协议特点

• 无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;
• 不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;
• 面向数据报: 不能够灵活的控制读写数据的次数和数量，应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;

2.协议格式

• 16位的UDP长度：UDP数据的长度
• 16位UDP校验和：校验数据在传输过程中是否失真
• 缓冲区：UDP的socket既能读, 也能写, 这个概念叫做 全双工
  UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后
  续的传输动作;
  UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果
  缓冲区满了, 再到达的UDP数据就会被丢弃;
• 注意：对于超过UDP传输大小的应用层数据，需要应用层自己进行分包传输。分包传输本质上就是需要应用层程序自定制应用层协议，应用层协议当中应当满足分包/合包的要求＋可靠传输

3.UDP的应用

• NFS: 网络文件系统
• TFTP: 简单文件传输协议
• DHCP: 动态主机配置协议
• BOOTP: 启动协议(用于无盘设备启动)
• DNS: 域名解析协议

4.TCP协议

1.面向连接

三次握手：

• 客户端先给服务器发送SYN数据包（连接数据包）
• 服务器收到后，给客户端回复ACK+SYN数据包（ACK作用是服务端告诉客户端收到了SYN数据包，后面的SYN是服务端告诉客户端“我也想和你进行连接”）
• 然后客户端给服务端发送ACK（作用是告诉服务端已经收到了SYN数据包）
• 对于客户端，状态是 ESTEBALISHED则连接建立；
• 此时服务端状态是 SYN_RCVD，认为连接未建立；
• 当前连接还在内核未完连接成队列中，即使服务端调用accept也不会将连接从内核中拿回；
• 只有客户端回复ACK，状态变成 ESTEBALISHED，连接才建立，服务端调用accept函数才能从已完成队列中取回连接

四次挥手（双方都有可能作为主动断开方）：

• 客户端发送FIN，状态变为FIN_WAIT1，服务端收到FIN，状态变为CLOSEWAIT（等待关闭连接状态）；
• 服务端回复一个ACK，客户端收到后状态变为FIN_WAIT2；
• 服务端发送FIN，状态从CLOSE_WAIT变成LAST_ACK，客户端收到后，状态变为TIME_WAIT；
• 客户端回复一个ACK，并且等待一会（时间为2MSL）从TIME_WAIT状态变为CLOSED，服务端收到ACK报文后，其状态也变为CLOSED；

为什么不是两次和四次握手？

• 两次：第二次S端回复ACK：
  只会进行单向通信且不能应答，而tcp的全双工通信
  第二次S端回复ACK+SYN：
  失败：会导致C一直发送SYN，S保存连接资源从而导致资源耗尽
  成功：S收不到ACK就会一直发送ACK+SYN；
  二次握手完成后：
  双方以为成功开始通信，实际没有S端发送消息会造成网络拥堵
• 四次握手：
  把ACK和SYN分开发送，理论上可以，但是会浪费资源
  如果不拆开，C就再次发送SYN，这样做无意义

为什么需要四次挥手？

• 因为tcp是全双工通信，每个方向都必须单独进行关闭
• 一端完成数据发送后，就发送FIN终止该方向的数据发送，对端收到FIN后就会通知其应用层 对端已终止数据发送

为什么最后一次ACK要等待2MSL？

tcp要保证最后一次报文送达后才断开连接
等待就是防止ACK报文丢失，如果丢失服务器就会重发FIN，客户端不等待就关闭的话服务器无法收到回复
2MSL就是报文往返的最长时间

2.协议格式

• 32位序号：该条TCP数据携带的起始序号
• 32位确认序号：期望对方发送数据的时候从哪个序号开始发（对方管理的序号）
  确认序号=上一次对方发送的数据起始序号+数据长度
• 4位首部长度：报头长度
• 标志TCP类型的标志位：
  URG:紧急标志位
  ACK：确认标志位
  PSH：发送数据标志位
  RST：重置连接标志位
  SYN：连接发起标志位
  FIN:断开连接标志位
• 16位窗口大小：消息接收方告诉消息发送方，自己的接收能力是多少，单位字节动态变化的
• 16位校验和：检验数据在发送过程中是否失真
• 16位紧急指针：配合URG标志位，发送带外数据
• MSS：最大报文段长度，决定TCP连接双方每次发送数据的最大值
  在三次握手中协商这个值，取连接双方较小的值（MSS=min(客户端MSS，服务端MSS)）
  协商最大报文段是长度为了防止报文过大，在网络当中数据丢失，引发后续的超时重传机制
  MSS的值收到了数据链路层MTU的影响（MTU：最大传输单元，是网卡传输数据帧的一个限制）

3.可靠传输

1.保证数据可靠有效的到达对端

确认应答机制：

• 现象：发送消息需要接收方进行确认
• 结论：本质上是对序号的确认，方法是接收方通过“确认序号”告诉发送方：期望发送方发送下一个序号的数据
• 隐含含义：上一个序号之前的数据都收到了，所以才会期望下一个序号的数据

超时重传机制：

• 理论：当发送方发送时启动超时重传计时器，当计时的时间超过“超时重传时间”后，还没有收到确认应答则重传该报文
• RTO:超时重传时间（RTO=RTT（上次）i+RTT(上上次)（1-i）,i的系数一般取0.9）

2.提高传输效率

1.自身发送的数据量

考虑:如果网络情况比较差，TCP发送数据完全不考虑网络转发能力，则丢失的TCP数据包就会越来越多，则重传的数据包也就越来越多，从而网络当中的数据量越来越多。如此传输，只能越来越糟糕。

• 1.网络本身转发能力就差，数据量确变多了。
• 2.tcp本身要保证可靠，但是丢包越高。
  所以:TCP就需要考虑传输效率的问题，考虑传输效率得要从三个方面考虑

滑动窗口机制：

• 理论：允许窗口大小的数据发送到网络当中进行传输，提高数据吞吐量
• 窗口大小：指的是不需要等待确认应答包而可以继续发送数据包的最大值
• 优点：在不考虑网络的情况下，可以提高发送数据量，因为发送的越多，传输的越多
• 缺点：需要防备数据丢失的情况触发超时重传，一旦触发超时重传，则数据就需要重新发送过去，也就是意味着发送方在没有接收到确认之前，是需要将数据缓存起来的（这个就是TCP的发送缓冲区）
• 滑动窗口将发送缓冲区划分为几个区域：
  1.已经发送，且收到确认的区域
  2.窗口区域：已经发送还没有收到确认应答；可以发送
  3.暂时不能发送
• 问题：1.分组ACK丢失：当多个分组中某个分组的ACK丢失时，可以通过后续分组的确认应答进行确认，发送方不会触发超时重传
  2.数据丢失：一定会触发数据重传，在发送方还没有触发超时重传机制的时候，数据就已经快速重传了

2.对方的接收能力

• 考虑场景:发送方发送的大量窗口数据被接收方接收之后，接收方的tcp缓冲区（网络协议栈的，不是应用层的）空间就会急剧的减少，此时发送方就需要降低发送速率（滑动窗口控制)，减少发送的数据量。

• 流量控制机制：接收方通过窗口大小来控制发送方的发送频率
• 方法：通过tcp包头中的窗口大小来控制，窗口大小的数值即接收方的接受能力
• 0窗口：接收方发送窗口大小为0的数据包给发送方，称之为0号窗口通告，是为了告诉发送方自己接受不了了，别发送了
• 重新恢复发送：1.发送方发送窗口探测包，询问接收方是否能发送数据；
  2.接收方主动发送窗口更新通知（本质上发送一个窗口不是0的窗口）

• 延迟应答机制：接收方接收到数据之后，等待一小会(200ms)，在200ms内等待应用层将数据读走，这样，接收缓冲区的空间变大之后，在进行应答（此时，确认应答当中的窗口大小就比之前的大)

3.网络转发能力

• 拥塞控制机制:基于想要探测网络转发能力的需求,tcp还维护了拥塞窗口(cwnd)，是发送方维护的一个状态变量，会根据网络的拥塞程度动态变化的。简单说:网络转发能力好，拥塞窗口大网络转发能力弱，拥塞窗口小
• 发送的数据大小=min(发送窗口，拥塞窗口)，发送窗口的大小取决于接收方的接收能力，用色从光口取决于网络的转发能力

如何动态维护拥塞窗口大小呢？

• 慢启动：
  随着轮询次数的增加，拥塞窗口呈现指数增长，直到拥塞窗口到达慢开始门限，当到达慢开始门限，执行拥塞避免算法
• 拥塞避免：
  随着轮询次数的增加，拥塞窗口呈现线性（每次拥塞窗口大小增加1）增长，知道发送拥塞（发送拥塞
  的标志就是tcp丢包)
• 快恢复：
  计算新的慢开始门限（阈值)=拥塞发生时拥塞窗口的/2; 拥塞窗口大小=新的慢开始门限值；执行拥塞避免算法
• 捎带应答机制：
  
  接收方给消息发送方回复数据的时候捎带上确认应答本质上就是回复的TCP数据当中的PSH标志位和ACK标志位置为1；

TCP当中的计时器：

• 超时重传计时器、TIME_WAIT计时器、保活计时器
• 保活计时器:判断连接是否正常的?
  1.服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时
  ⒉.若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段（保活数据包/探测数据包/心跳)，以后则每隔75秒钟发送一次。
  若连续发送10个探测报文段后仍然无客户端的响应，服务端就认为客户端出了故障，接着就关闭这个
  车接。

4.面向字节流

创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;

• 调用write时, 数据会先写入发送缓冲区中;
• 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
• 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
• 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
• 然后应用程序可以调用read从接收缓冲区拿数据;
• 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可
  以写数据. 这个概念叫做 全双工
• 由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如: 写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节; 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;