【01】网络基础（科普篇）

1. 说说TCP的三次握手

传输控制协议TCP简介

• 面向连接的、可靠的、基于字节流的传输层通信协议

• 将应用层的数据流分割成报文段并发送给目标节点的TCP层

• 数据包都有序号，对方收到则发送ACK确认，未收到重传

• 使用校验和来检验数据在传输过程中是否有误

TCP报文头

TCP FLags

• URG: 紧急指针标志
• ACK: 确认序号标志
• PSH： push标志
• RST：重置链接标志
• SYN：同步序列号，用于建立连接过程
• FIN：finish标志，用于释放连接

• 三次握手

三次握手

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

1. 第一次握手：建立连接时，客户端发送SYN包（syn=j）到服务器，并进入SYN_SEND状态，等待服务器确认；
2. 第二次握手：服务器收到SYN包，必须确认客户端的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（ack=k+1）,此包发送完毕，客户端和服务器端进入ESTABLSHED状态，完成三次握手。

• 为什么需要三次握手才能建立起连接

• 为了初始化Sequence Number的初始值
• TCP需要拼接各端的seq number

• 首次握手的隐患——SYN超时

• 问题起因分析

1. Server收到Client的SYN，回复SYN-ACK的时候未收到ACK确认
2. Server不断重试至超时（5次，1+2+4+8+16+32秒），Linux默认等待63秒TCP才能断开连接

• 针对SYN Flood的防护措施

• 服务器被恶意程序SYN发送报文占用，等待63秒期间进行攻击
• SYN队列满后，通过tcp_syncookies参数回发SYN Cookie
• 若为正常连接则Client会回发SYN_Cookie，直接建立连接

建立连接后，Client出现故障怎么办

• 保活机制
  • 向对方发送保活探测报文，如果未收到响应则继续发送
  • 尝试次数达到保活探测数仍未收到响应则中断连接

2. 说说TCP的四次挥手

挥手是为了终止连接，TCP四次挥手的流程图如下：

四次挥手

MSL最长报文时间：

TCP采用四次挥手来释放连接

• 第一次挥手： Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态；
• 第二次挥手： Server收到FIN后，发送一个ACK给Client，确认序列号为序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态；
• 第三次挥手： Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态；
• 第四次挥手： Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

为什么会有TIME_WAIT状态

• 原因：

1. 确保有足够的时间让对方收到ACK包
2. 避免新旧连接混淆

为什么需要四次挥手才能断开连接

因为TCP是全双工的，发送方和接收方都是需要FIN报文和ACK报文

服务器出现大量CLOSE_WAIT状态的原因

• 客户端关闭socket连接，服务端忙于读或写，没有及时关闭连接

• 检查代码，特别是注释代码

• 检查配置，特别是处理请求的线程配置

查看服务器连接情况
netstat -n | awk '/^tcp/{++S[$NF]}END{for(a in S) print a,S[a]}'

3. TCP 滑动窗口

RTT和RTO

• RTT：发送一个数据包到收到对应的ACK，所花费的时间
• RTO：重传时间间隔

• TCP使用滑动窗口做流量控制与乱序重排

• 保证TCP的可靠性
• 保证TCP的流控特性

• 窗口数据的计算过程

窗口数据的计算过程

AdvertisedWindow = MaxRcvBuffer - (LastByteRcvd - LastByteRead)

TCP会话的发送方
滑动窗口的大小可以通过一定的策略动态调整
根据应用根据自己处理能力的变化，通过本端TCP处理能力大小，对本端的发送窗口调整做流量限制

4. UDP

UDP的特点

• 面向非连接
• 不维护连接状态，支持同时向多个客户端传输相同的消息
• 数据包报头只有8个字节，额外开销较小
• 吞吐量只受限于数据生成速率、传输速率以及机器性能
• 尽最大努力交付，不保证可靠交付，不需要维护复杂的链接状态表
• 面向报文，不对应用程序提交的报文信息进行拆分或者合并

结论

TCP和UDP的区别

1. 面向连接VS无连接
2. 可靠性（握手、确认和重传机制）
3. 有序性（序列号）
4. 速度（创建连接、排序等）
5. 量级（源数据头大小，TCP20个字节，UDP8个字节）

5. HTTP简介

超文本传输协议HTTP主要特点

1. 支持客户/服务器模式
2. 简单快速，只需要传输请求方式，规定请求类型，规模小
3. 灵活，允许传输各种类型数据，contentType标记
4. 无连接，限制每次连接只处理一个请求，服务器处理完请求，即开始断开客户端连接，默认使用长连接以保证连接特性，keepline,每个独立无法知道是否是长连接
5. 无状态，协议对事务处理无记忆，每次需要重复数据需要重传

• HTTP请求结构

HTTP请求结构

• HTTP响应结构

HTTP响应结构

• 一个url请求在浏览器到访问到背后经历了那些操作

1. DNS解析，浏览器、系统、路由器、ips、域名、顶级域名、根域名
2. tcp连接，三次握手
3. 发送HTTP请求
4. 服务器处理请求并返回HTTP报文
5. 浏览器解析渲染
6. 连接结束，四次挥手

• 五种可能的取值

• 1xx: 指示信息-表示请求已接受，继续处理
• 2xx: 成功--表示请求已被成功接收、理解、接手
• 3xx: 重定向--要完成请求必须进行更进一步的操作
• 4xx: 客户端错误--请求有预发错误或请求无法实现
• 5xx: 服务器端错误--服务器未能实现合法的请求

• Cookie和Session的区别

• Cookie:

1. 是由服务器发给客户端的特殊信息，以文本的形式存放在客户端
2. 客户端再次请求的时候，会把Cookie回发
3. 服务器接收到后，会解析Cookie生成与客户端相对应的内容

• Cookie的设置以及发送过程
  Cookie设置以及发送过程

• Session

1. 服务器端的机制，在服务器端上以散列表的形式保存的信息
2. 解析客户端请求并操作sessionId，按需保存状态信息

• Session的实现方式

• 使用Cookie来实现

session实现

• 使用URL回写方式来实现

• Cookie和Session的区别

• Cookie数据存放在客户的浏览器上，Session数据存放在服务器上
• Session相对于Cookie更安全
• 若考虑减轻服务器负担，应该使用Cookie

6. HTTP和HTTPS的区别

HTTPS
超文本安全传输协议

HTTP和HTTPS协议对比

SSL（Security Sockets Layer,安全套接层）

• 为网络通信提供安全及数据完整性的一种安全协议
• 是操作系统对外的API，SSL3.0后更名TLS
• 采用身份验证和数据加密保证网络通信的安全和数据的完整性

加密的方式

1. 对称加密：加密和解密都是用同一秘钥
2. 非对称加密： 加密是用的秘钥和解密是用的秘钥是不相同的
3. 哈希算法：将任意长度的信息转换为固定长度的值，算法不可逆
4. 数字签名：证明某个消息或者文件是某人发出或被认同的

• HTTPS数据传输流程

• 浏览器将支持的加密算法信息发送给服务器
• 服务器选择一套浏览器支持的加密算法，以证书的形式回发浏览器
• 浏览器验证证书合法性，并结合证书公钥加密信息发送给服务器
• 服务器使用私钥解密信息，验证哈希，加密响应消息回发浏览器
• 浏览器解密响应消息，并对消息进行验证，之后进行加密交互数据

• HTTPS与HTTP区别

• HTTPS需要到CA申请证书，HTTP不需要
• HTTPS密文传输，HTTP明文传输
• 连接方式不同，HTTPS默认使用443端口，HTTP默认80端口
• HTTPS=HTTP+加密+认证+完整性保护,较HTTP安全

7. Socket

Socket是对TCP/IP协议的抽象，是操作系统对外开放的接口

socket作用域

Socket通信流程

Socket通信流程

image.png