网络知识基础--老先生

今日完成：

周五用了很多时间在环境配置上，之后把前端页面改完，要改动上传文件并读取其中信息的接口，这个在把之前的前后端代码逻辑理清楚之后大致思路已经明确了。下周一就把这部分批量上传做完。周末复习了一下网络知识，之前这部分已经忘记了很大一部分。

周一要求：

周一要把批量上传尽快做完。之后再看还有没有新的任务要求。这周配环境连着影响三天，周一得把丢掉的时间补上，按照自己正常效率应该这周就能完成这个邮件发送才对。

网络知识基础：

tip1：七层架构

物理层/数据链路层/网络层/传输层/会话层/

会话层：应用之间的会话联系

表示层：定义信息的语法语义，如加密解密/压缩解压缩

应用层：重点http协议，规定消息头的格式。

发送方先在上而下处理数据，发送出去后，接收方自下而上处理。

tip2：TCP/IP OSI实现

TCP：

TCP flag

URG：紧急指针标志

ACK：确认序号有效

PSH：push标志

RST：重置连接标志

SYN：同步序号，用于建立连接过程

FIN：finish标志，用于释放连接

三次握手：

客户端主动打开，服务器被动打开

第一次握手：客户端从CLOSED打开，发送SYN=j序列号，服务器处于LISTEN，客户端进入SYN-SENT

第二次握手：服务器收到SYN，自己发送SYN=k和确认ACK=j+1,服务器LISTEN进入SYN-RCVD

第三次握手：客户端发送ACK=k+1,进入ESTAB-LISHED状态，服务器收到，进入ESTAB-LISHED

之后就可以互相通信了。

TCP 中的Sequence Number发送的这个包中第一个字节（如果有payload的话）的序号

我已经发送了前100字节的数据，那么我下一个发送的包（如果发送窗口还有空间）的SEQ就是101，比如要发送10字节的数据，那么下一个包中的数据的字节编号就是 101 - 110. 之后如果继续发送的话，序号就是从111开始。

如果接收端接到了这个10字节的包的话，便会返回一个 ACK 为 111 的包，表示前面110个字节已经成功接收。

此外SYN/ACK都要占一个字节

三次握手的目的是为了初始化Sequence Number。

针对攻击，如果SYN队列满了，通过tcp-syncookies参数回发SYN Cookie，如果客户端正常连接会回发SYN Cookie，直接建立连接。（攻击者发完SYN下线了

建立连接后Client故障怎么办，向对方发送保活报文，没收到就继续发送，达到报货探测数还没响应就中断

四次挥手：

挥手是为了终端连接

第一次挥手：Client发送一个FIN，之后进入FIN_WAIT_1状态

第二次挥手：Server收到FIN后，发送ACK给Client，确认序号为收到的序号+1（与SYN相同，一个FIN占用一个序号，Server进入CLOSEN_WAIT状态

第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态

第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

TIME_WAIT是为了让对方收到ACK（这个是客户端的最后的状态)

四次握手目的是因为全双工，双方都要收到FIN ACK

出现大量CLOSEN_WAIT（这个是服务端的中间状态)可能对方关闭socket连接，我方忙于读和写，没有及时关闭连接

TCP/UDP

UDP面向非连接

不维护连接状态，支持同时向多个客户端传送相同消息

数据包报头只有8字节，开销小

吞吐量只受限于数据生成速率/传输速率/机器性能

不需要维持复杂连接状态，不保证可靠，尽最大努力交付

面向报文，不对其进行拆分或者合并

UDP属于轻量级，只有8字节，TCP有20字节