应用层协议@传输层协议

1、自定制协议：

2、知名协议：

HTTP协议实现

HTTP协议格式

3. UDP协议

3.1 UDP协议端格式:UDP协议报头只有8个字节

3.2 UDP特点

4. TCP协议

4.1 TCP协议端格式

4.2 TCP数据传输格式

4.3 确认应答机制

4.4 超时重传机制

4.5 TCP应答管理机制

应用层协议：应用层是面对程序员的一层，应用程序是程序员自己写的，因此应用层协议由程序员自己决定。

1、自定制协议：

序列化：将多个数据对象按照指定的协议进行组织成为持久化存储/数据传输的二进制数据串。
反序列化：将二进制数据串通过指定协议进行解析得到各个数据对象。
序列化方式：结构体二进制序列化，json，protobuf.

2、知名协议：

HTTP-应用层的超文本传输协议-html。
网址：URL-统一资源定位符-定位网络中某台主机上的某个资源。
如何定位：url包含的要素-协议方案名称://用户名:用户密码@服务器IP:服务器PORT/资源路径?查询字符串#片段标识符
协议方案名称：确定本次请求使用什么协议。
用户名/密码：本次访问的客户端认证信息（很少使用）。
服务器IP/PORT：定位网络中的一台主机上的处理进程。
资源路径：请求服务器上的某个资源。
查询字符串：客户端提交给服务端的数据，由key=value键值对组成，键值对之间以&符号进行间隔。
urlencode：url编码，提交的数据中不能出现特殊字符，一旦包含就要进行转义，将特殊字符每个字节转换为16进制数字字符，使用%标识。
urldecode：url解码，在查询字符串中遇到%，将其第一个字符转换为数字乘以16加上第二个字符转换后的数字。

HTTP协议实现

抓包工具：wireshark/fiddler.
wireshark：网卡抓包工具，抓取流经网卡的所有数据流量-什么包都能抓。
fiddler：浏览器的代理工具，通过代理实现数据抓包-专业的http抓包工具。
http/https：https是加密后的http协议，若要抓取https中的数据，则需要进行配置。

HTTP协议格式

请求：

首行：GET http://123.207.58.25/admin HTTP/1.1 以空格进行间隔包含三个要素，最终以\r\n作为结尾。

请求方法：GET/POST/HEAD/PUT/DELETE/CONNECT/PATCH/OPTIONS/TRACE

GET-请求实体资源-也可以通过url中查询字符串向服务器提交数据-数据不安全/url长度有限制（各个服务器应用商的限制）
POST-主要用于向服务器提交数据，提交的数据在正文中；GET请求没有正文，POST请求有正文。
HEAD-类似于GET，相较于GET，HEAD只响应头部，而不响应正文。

URL： http://123.207.58.25/admin

协议版本：HTTP://1.1 0.9/1.0/1.1/2.0

0.9：仅用于传输html数据，并且只有GET请求方法且协议格式不完整。
1.0：正式规定了http协议格式，并且增加了多种请求方法且支持了不同文件格式的数据流。
1.1：在1.0的基础上增加了更多请求方法和头部描述信息且支持了长连接，管线化传输（响应的顺序必须与请求的顺序保持一致）。
2.0：采用二进制流传输，并且进行多路复用（响应顺序可以不用与请求顺序保持一致，头部标识了请求信息）且允许服务端主动推送数据。
短连接：http基于在传输层tcp实现通信，建立连接，发送一个请求，得到响应后，则关闭连接。
长连接：一次连接可以发送多条请求。

头部：描述本次请求的关键字段信息，由key:val形式的键值对组成，并且每个键值对以\r\n作为结尾 key:val\r\nkey:val\r\n

Connection-控制长/短连接
Cache-Control-缓存控制
User-Agent-客户端属性
Accept-描述自己所能接收的数据属性
Content-Length-描述正文长度
Content-Type-描述正文数据类型

早期http是短连接通信，是一个无状态协议，不会保存客户端的状态，每次访问都需要进行登录，因此引入Cookie保存客户端状态，Cookie-持续在通信中描述客户端的通信状态，但是不够安全。

空行：间隔头部与正文；接收http数据的时候，当连续收到两个\r\n（\r\n\r\n）的时候，则认为头部到此结束。

先获取完整头部，通过头部中的Content-Length获取正文长度，然后获取指定长度正文，通过这种方式每次获取完整一条http请求数据。

正文：提交给服务端的数据。

响应:

首行：HTTP/1.1 303 See Other 包含三个要素，以空格进行间隔，以\r\n作为结尾

协议版本：0.9/1.0/1.1/2.0

响应状态码：表示对本次的请求服务端所做出的响应结果

1xx：描述信息
2xx：表示本次请求正确处理完毕典型 200
3xx：重定向-请求的资源在另一个位置，要求客户端重新请求新位置；301-永久/302-临时
4xx：表示客户端请求错误；400-请求错误/404-表示请求的资源不存在
5xx：表示服务端错误；500-服务器内部错误 / 502-代理请求失败，无效响应 / 504-代理请求超时

状态码描述：对状态码的描述信息，可以是官方文档对应描述，也可以自定义。

头部：关于本次响应的一些关键字段描述信息，以key:val键值对组成，以\r\n作为结尾

Transfer-Encoding：实体正文的传输方式
Expires：缓存过期时间
Location-3xx 重定向的新位置
Set-Cookie-服务端通过set-cookie向客户端传递信息，会被保存在客户端浏览器的cookie文件中。
Cookie-客户端每次通信从cookie文件读取数据通过cookie向服务端传递信息（维持客户端状态信息)，cookie的使用不够安全，因此使用Session搭配使用。
Session-会话，服务端会为每个登录的客户端创建会话，在服务端描述一些会话信息（客户端身份信息，状态信息)，保存在服务端，可以通过set-cookie将session id 返回给客户端，客户端每次通信都会通过cookie带有自己的sessio id;
cookie和session区别：cookie持续传递客户端状态信息的字段，保存在客户端，用于持续与服务端进行信息传递的一种手段。session是一种会话的控制，服务端保存的会话信息包含客户端的身份状态信息，通过cookie/set-cookie传递的session id 进行客户端的身份状态识别。

3. UDP协议

3.1 UDP协议端格式:UDP协议报头只有8个字节

16位源端端口/16位目的端端口：描述端与端之间的通信；
16位UDP长度：表示整个数据报（udp首部+udp数据）的最大长度，即数据报最大大小位2^16byte=64kb；
16位校验和：使用二进制反码求和算法，校验接收的数据与发送的数据是否一致；（二进制反码求和算法->对报文从头开始每个字节进行取反相加，高出16位则截断高位，与低16位继续相加，得到校验和）

3.2 UDP特点

无连接：知道对端的IP和端口号就直接进行传输, 不需要建立连接；
不可靠：没有确认机制, 没有重传机制；如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层
返回任何错误信息；UDP不保证数据的可靠, 有序到达, 因此有可能乱序, 需要在应用层进行包序管理；
面向数据报：应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并, 并且最大长度64KB；如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装。

3.3 UDP的缓冲区

UDP没有真正意义上的发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;
UDP的socket既能读, 也能写, 这个概念叫做 全双工。

3.4 基于UDP的知名协议

DHCP: 动态主机配置协议；
DNS: 域名解析协议

4. TCP协议

4.1 TCP协议端格式

源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;
32位序号/32位确认号: 实现tcp的包序管理->tcp数据是有序交付的；
4位TCP报头长度: 以4字为位单位描述tcp报头长度，tcp报头是不定长的，最小20字节，最大15 * 4 = 60字节；
6位标志位:

URG: 紧急指针是否有效
ACK: 确认号是否有效
PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段

16位窗口大小: 实现滑动窗口机制，进行流量控制；
16位校验和: 二进制反码求和算法，校验数据一致性；
16位紧急指针: 标识哪部分数据是紧急数据;
0~40字节选项数据：主要用于协商以及描述一些信息。

4.2 TCP数据传输格式

TCP发送数据，是以字节流的形式发送。它不关心数据是什么类型，但是为了确保数据正确性，重发控制和重复控制等, 这些功能都以序列号来实现. 序列号初始值并非为0，而是由客户端建立连接时候，随机产生的；
TCP的数据长度并未写入TCP首部。实际通信中求得TCP包的长度的计算公式是：IP首部中的数据包长度 – IP首部长度-TCP首部长度；
TCP将每个字节的数据都进行了编号. 即为序列号. 每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发。

4.3 确认应答机制

当数据从主机A发送给主机B时，主机B会返回给主机A一个确认应答。

4.4 超时重传机制

主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B; 如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发

主机A未收到B发来的确认应答, 也可能是因为ACK丢失了，因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出哪些包是重复的包, 并且把重复的丢弃掉. 这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果。

那么, 超时的时间如何确定?

最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”，但是这个时间的长短, 随着网络环境的不同, 是有差异的.
如果超时时间设的太长, 会影响整体的重传效率;
如果超时时间设的太短, 有可能会频繁发送重复的包;

TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.

Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.
如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.
如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增.
累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接

4.5 TCP应答管理机制

服务端状态转化:

[CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接;
[LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送SYN确认报文.
[SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了.
[ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器返回确认报文段并进入CLOSE_WAIT;
[CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)
[LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK, 彻底关闭连接

客户端状态转化:

[CLOSED -> SYN_SENT] 客户端调用connect, 发送同步报文段;
[SYN_SENT -> ESTABLISHED] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据;
[ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时, 向服务器发送结束报文段, 同时进入FIN_WAIT_1;
[FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认, 则进入FIN_WAIT_2, 开始等待服务器的结束报文段;
[FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出LAST_ACK;
[TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入CLOSED状态

为什么是三次握手

如果client发送的连接请求由于网络延时到client连接释放后才到达server，这是早已失效的报文，如果只进行二次握手，服务器就认为有新连接请求，但是client并没有建立连接，不会给server发送数据，但是server为了这个连接，会一直有资源消耗。

为什么是四次挥手

客户端发送FIN包，表示客户端不再发送数据，不表示客户端不再接收数据，因此被动关闭方进行ACK回复之后有可能还会继续发送数据，等到不再发送数据，才会发送下一个FIN包，因此FIN和ACK是分开的。

TIME_WAIT状态有什么用？为什么主动关闭方没有直接进入closed释放资源？

假设主动关闭方最后一次的ACK丢失，被动关闭方没有收到最后一次ACK，超时后就会重传一个FIN。
假设客户端没有TIME_WAIT而是直接释放资源，就有可能启动新的客户端且使用与之前客户端相同的地址信息。刚启动新的客户端绑定地址成功，收到重传的FIN包，对新连接造成影响；新启动的客户端，若是向相同的服务端发送SYN，因为服务端处于LAST_ACK，需求的是ACK而不是SYN，因此就会发送RST。
因此若主动关闭方最后一次回复后直接释放资源，就有可能会对新启动的新连接造成影响，因此必须等待一段时间，能够处理有可能重传的FIN。
等待比较合适的时间->2个MSL时间（MSL->报文最大生存周期）。1、处理重传的FIN包；2、等到本次通信的所有报文都消失在网络中，避免对新连接造成影响。

TCP三次握手失败，服务端如何处理？

没有收到SYN，什么都不做；
回复了SYN+ACK，但长时间没有收到响应，则超时后发送RST重置连接报文，释放资源。

一台主机上出现大量的TIME_WAIT是什么原因？如何处理？

TIME_WAIT是主动关闭方出现的，一台主机上出现大量的TIME_WAIT说明这台主机主动关闭了大量的连接，常见于一些爬虫服务器。
处理方法：调整TIME_WAIT等待时间，也可使用开启地址重用的套接字选项->setsockopt。（地址重用->允许套接字绑定使用中的地址端口，常用于防止socket处于TIME_WAIT无法使用相同地址信息进行绑定新的套接字）

一台主机上出现大量的CLOSE_WAIT是什么原因？如何处理？

CLOSE_WAIT是被动关闭方收到FIN请求进行回复之后的状态，等待上层程序进行进一步处理。若出现大量CLOSE_WAIT，有可能是被动关闭方主机程序中忘记了最后一步断开连接后调用close释放资源。

TCP连接管理中的保活机制：

tcp通信中，若两端长时间没有数据往来，则这时候每隔一段时间，服务端向客户端发送一个保活探测数据报，要求客户端进行修复，若连接多次没有收到响应，则认为连接断开。
长时间没有数据往来：默认7200s--->可配置，通过设置套接字选项配置。
每隔一段时间：默认75s--->可配置，通过设置套接字选项配置。
连续多次无响应：默认9次--->可配置，通过设置套接字选项配置。

可靠传输：

面向连接；
确认应答机制->发送数据后要求对方进行确认回复，才能知道对方是否收到了这条数据，通过序号与确认序号实现；
超时重传机制->发送数据等待确认响应超时之后，认为数据丢失，则进行重新传输；
通过序号/确认序号字段实现数据有序交付；
通过校验和字段校验数据一致性，不一致则要求对方进行重传。

seq：本条数据的起始序号，
ack：对对方发送数据的确认序号，告诉对方确认序号之前的数据已收到
三次握手时，双方会协商起始序号（上面例子从0开始，实际中不一定，是一个随机值），三次握手时，虽然数据长度为0，但是确认序号时对方发送的数据起始序号+1。（ack=seq+1，seq=ack）
数据通信时，确认序号是对方发送的数据起始序号+数据长度（ack=seq+len），告诉对方这个确认序号之前的数据都已收到。
数据连续发送时，第一条数据丢失，接收方直接收到了第二条和第三条，接收方就不会对第二条和第三条进行回复->因为确认序号确认的是这个序号之前的数据全部已收到。这么做的目的是->防止因为确认回复的丢失而导致的重传。如果因为网络原因，后发的数据先到，接收方也会根据协商的起始序号，根据每条数据中的起始序号，将数据在接收缓冲区中进行排序。

额外的丢包问题处理：

发送方发送数据过快，接收方来不及处理取出，接收缓冲区满溢，那么以后的数据都会被丢弃；
发送方发送大量的数据，但是因为网络状态不好导致大量丢包造成重传。

滑动窗口机制：依靠协议中的窗口大小字段实现流量控制

接收方通过协议中的窗口大小字段，告诉发送方，最多可以发送多少数据（窗口大小不大于接收方的接收缓冲区剩余空间大小->避免了发送的数据太多而缓冲区满了没处放的丢包）。
MSS：最大数据段大小，表示tcp数据通信时一条数据的最大大小，通信时双方进行协商，取双方mss中较小的一方作为最大数据段大小。
滑动窗口在发送方维护发送窗口/接收方维护接收窗口->窗口通过一个后沿序号/前沿序号实现。
发送窗口：表示一次最多从后沿到前沿最多发送多少数据->不超过接收方的窗口大小。
后沿：所要发送数据的起始序号，后延的移动取决于是否收到数据确认回复。
前沿：根据接收方窗口大小计算的结束序号，取决于接收方响应的窗口大小（前沿减去后沿就是接收方的窗口大小）
接收窗口：表示从哪里开始接收数据，接收到多少序号为止->不超过剩余空间大小，进行包序管理，哪个包应该放在缓冲区的什么位置。
后沿：接收数据的起始序号，后沿的移动取决于是否收到了数据。
前沿：根据接收缓冲区剩余空间大小计算得到的接收的数据的结束序号，前沿的移动取决于剩余空间大小。
窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。
操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;
窗口越大, 则网络的吞吐率就越高;

停等协议：得到一条回复，然后才能发送下一条数据。
回退n步协议：一条数据丢失了，则需要发送端将丢失这条数据以后的数据都进行重传。
选择重传协议：一条数据丢失了，则仅仅针对丢失的这条数据进行重传。
因为网络状态不好，导致发送的数据越多丢包的越多->拥塞控制。
拥塞控制：进行网络探测，以一种慢启动，快增长的传输方式，根据网络状态调整发送速度的机制。

提高传输性能的方式：

快速重传机制：发送端连续发送多条数据，若接收端接收数据并非是接收后沿数据，则认为有可能后沿数据丢失了，首先不会进行接收到的数据的确认回复，其次向发送端间隔连续发送三次后沿数据的重传请求，要求对方对后沿数据进行重传。发送方连续收到三条同一重传请求，则对这条数据进行重传。
为什么是三次：避免因为网络延迟，数据报的延迟到达，三次可以有一个缓冲时间，若在第二次的时候收到了后沿数据报，则不再发送第三条重传请求，这时候发送端也不用重传了。
快速重传，可以一定程度避免发送端必须的超时重传。
延时应答机制：接收方接收到数据之后，并不立即进行确认回复（因为如果立即进行确认回复，因为接收缓冲区剩余空间变小了，窗口就变小了，导致传输的吞吐量变小了），而是延迟应答，则有可能应答的时候程序在上层已经将数据取出，保证窗口大小不会变小。
捎带应答机制：接收方接收到数据之后，进行确认回复，确认回复就是一个报头中的确认序号进行的，为了减少空报头的响应占据带宽，则使用捎带应答，在即将要发送的数据头部中进行上一条接收到的数据的确认回复。

面向字节流：字节流传输服务是面向连接的，有序的一种最小以字节为传输单元的传输方式。

发送端在send发送数据的时候，并不会立即封装报头，而是将数据先放到发送缓冲区中，选择合适的时候再去从缓冲区中取出合适大小的数据进行传输。
接收端在recv接收数据的时候，并非一条一条向上交付，而是根据recv想要的数据长度从接收缓冲区中取出指定长度的数据进行交付。
优点：传输比较灵活，大量小的数据会集合成一条大的数据进行一次性传输，减少了IO次数提高了性能（延迟发送可以关闭，可配置），接收方接收也更加灵活，想要多少取多少。
缺陷：tcp交付的这条数据可能并非一条完整的数据，也有可能是多条数据（tcp对于上层给与的数据边界并不敏感，不关注是几条数据，只关注自己可以传输多少字节的数据/recv想要多少字节的数据）