1. 计算机网络分层
OSI模型
- 物理层
- 数据链路层
- 网络层
- 传输层
- 会话层
- 表示层
物理层：定义了物理设备的标准，传输比特流（二进制数据转换为强弱不同的电流，到达目的后再转换为机器码）
数据链路层：定义了如何格式化数据以及如何传输，提供错误检测以及纠正，将比特数据转换为帧
网络层：将网络地址翻译为对应的物理地址，并决定将数据从发送方路由到接收方，选择最佳路由。IP协议，IP数据包
传输层：接受上一层的数据，在必要的时候将数据进行分割。并将这些数据交给网络层，且保证这些数据段有效的到达接收方。TCP协议，UDP协议
会话层：自动收发包，自动寻址。在不同机器上的用户之间建立及管理会话，接触或建立与别的节点的联系
表示层：解决不同系统之间通信语法不同的问题，数据加密，代码转化、将数据以网络能理解的方案进行格式化。
应用层：规定接收方和发送方以一个固定长度的消息头，例如文件传输、电子邮件、文件服务、虚拟终端等。HTTP协议
2. TCP/IP协议
TCP：传输控制协议
- 面向连接的、可靠的、基于字节流的传输层通信协议
- 将应用层的数据流分割成报文段并发送给目标节点的TCP层
- 数据包都有序号，保证到目标节点的按序处理。对方收到则发送ACK确认，如果在合理的往返时延内未收到确认则重传
- 使用检验和来检验数据在传输过程中是否有误
TCP报文头部结构
-
源端口和目的端口： 各占2个字节，分别写入源端口号和目的端口号，源端口号在需要对方回信时选用，目的端口在终点交付报文的时必须使用
-
序号：在一个TCP连接中传送的字节流中的每一个字节都按顺序编号
-
确认号：是期望收到对方下一个报文段的第一个数据字节的序号。若确认号 = N，则表明：到序号N-1为止的所有数据都已正确收到
-
数据偏移： 指出TCP报文段的数据起始处距离TCP报文段的起始处有多远
-
Flags
- URG：紧急指针标志，为1表明紧急指针有效，告诉系统此报文段中有紧急数据，优先级高
- ACK：确认序号标志，仅当ACK=1时确认号字段才有效。TCP规定，在连接建立后所有穿梭那个的报文段必须把ACK置为1
- PSH：push标志，用于提高优先级
- RST：重置连接标志，当RST=1时，表明TCP连接中出现严重差错，必须释放连接并重新建立连接
- SYN：在连接时用来同步序号，当SYN=1而ACK=0时，表明这是一个连接请求的报文段，对方若同意建立连接，则响应的报文端中ACK=1且SYN=1。
- FIN： 用于释放一个连接，当FIN=1时，表明此报文段数据已发送完毕，并要求释放连接。
-
窗口： 窗口值作为接收方让发送方设置其发送窗口的依据，用于流量控制
-
检验和： 检验和字段检验的范围包括首部和数据两部分
-
紧急指针： 仅在URG=1时才有效，用于指出本报文段中的紧急数据的字节数。
-
可选项： 仅用于使整个TCP报文的首部长度是4的整数倍
TCP的三次握手
- 假设A、B首次建立通信
- 服务端创建传输控制块TCP时刻监听客户端发送的请求，服务端进入Listen状态
- 客户端创建传输控制块TCP向服务器发送连接请求报文，SYN=1 初始序号为 x，客户端进入SYN-SENT（同步已发送）状态 （第一次握手）
- 服务端收到请求报文后，若同意建立连接，则向A发送确认报文段、在确认报文段中应把ACK 和 SYN都置为1，确认号ack=x+1(因为请求报文段中消耗了一个序号)、为自己的缓存初始化序列号seq=y。服务端进入SYN-RCVD（同步收到）状态 (第二次握手)
- 客户端接收到服务端的确认报文后，还要给服务端发送确认报文，确认报文中ACK=1、确认号ack=y+1,自己的序号seq=x+1，这时TCP连接已经建立，客户端和服务端进入ESTANLISHED（已建立连接）状态 （第三次握手）
为什么需要三次握手才能建立连接
-
为了初始化seq（序号）的初始值，以保证传输的数据不会因为网络上的问题而乱序
-
首次握手时的隐患——SYN超时
-
问题起因分析
-
客户端收到服务端的SYN，回复的SYN-ACK的时候未收到ACK确认
-
服务端不断重试直至超时，Linux默认等待63s才能断开连接
-
针对SYN Flood的防护措施
- SYN队列满后，通过tcp_syncookies参数回发SYN Cookie
- 若为正常连接则服务端会回发SYN-COOKIE,直至完成连接
-
-
建立连接后，客户端出现故障怎么办
- 向对方发送保活探测报文，如果未收到响应则继续发送
- 尝试次数打到保活探测数仍未收到响应则中断连接
-
-
TCP的四次挥手
-
假设数据传输过程中，由客户端进程主动关闭，则服务端被动关闭
-
客户端进程先向其TCP发送***连接释放***报文段，并停止再发送数据，连接释放报文段中将终止控制位FIN置为1，seq=u（等于已传送过的数据的最后一个字节的序号加1）客户端进入FIN–WAIT-1（
终止等待）状态，等待B确认。FIN报文段即使不携带数据，它也消耗一个序号。 （第一次挥手） -
服务端进程收到连接释放报文段后即发出确认，确认号是ack=u+1，seq为v（等于客户端前面已传送的数据的最后一个字节的序号加1），然后服务端进入CLOSE-WAIT（关闭等待）状态。TCP服务器此时会通知高层应用进程，因为从客户端到服务端这个方向的连接就被释放了，这是TCP连接处于半关闭状态，这时客户端已经没有数据向服务端发送了，但是服务端要发送数据，客户端仍要接收。也就是说，从服务端到客户端这个方向的连接还没有关闭，这个状态可能会持续一段时间。（第二次挥手）
-
客户端收到服务端的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待服务端发送的连接释放报文段。
-
若服务端已经没有向客户端发送的数据，其应用程序就通知TCP释放连接，这时服务端发送的连接释放报文必须时FIN置为1，假定服务端进程的序号为w（在半关闭状态可能又发送了一部分数据）。服务端还必须重复上次已经发送的确认号ack=u+1，这时服务端进程进入LAST-ACK（最后确认）状态，等待客户端的确认。 （第三次挥手）
-
客户端收到服务端发送的连接释放报文后，必须对此进行确认。在确人报文段中吧ACK置为1，确认号ack=w+1,而自己的序号seq=u+1，然后进入TIME-WAIT（时间等待）状态。此时客户端进程的TCP连接还没有释放掉，必须等待时间等待计时器设置的时间2MSL之后，客户端才能进入CLOSED状态。RFC793建议为2min，Linux为30s，而服务端接收到客户端的确认报文后，立即进入CLOSED状态关闭连接。（第四次挥手）
为什么会有TIME-WAIT状态（为什么要等待2MSL）
- 确保有足够的时间让对方收到ACK包
- 避免新旧连接混淆
为什么需要四次挥手才能断开连接
- 因为TCP协议是全双工，发送方和接收方都需要FIN报文和ACK报文
服务器出现大量CLOSE_WAIT状态的原因
-
客户端发送了一个连接释放的报文之后，服务器端没有发送确认报文，即客户端关闭了socket连接，但服务端忙于读或写，没有及时的关闭连接。
- 检查代码，特别是释放资源的代码
- 检查配置，特别是处理请求的线程配置