目录
OSI 开放式互联参考模型（先 自上而下，后自下而上 处理数据头部）
OSI 的"实现"：TCP / IP
TCP 的三次握手
传输控制协议 TCP：
面向 连接的、可靠的、基于字节流 的传输层通信协议。
将 应用层的数据流 分割成报文段并发送给目标节点的TCP层。
数据包都有序号，对方 收到则发送ACK确认，未收到则重传 。
使用 校验 来检验数据在传输过程中是否有误。
TCP Flags （tcp 标志）
URG：紧急指针标志。
ACK：确认序号标志。
PSH：push标志。（push）
RST：重置连接标志（reset）。
SYN：同步序号，用于建立连接工程。（synchronize）
FIN：finish标志，用于释放连接。（finish）
“握手”是为了建立连接
Client（客户端）：喂？！听得到吗？
Server（服务端）：听得到，你听得到我讲的吗？
Client（客户端）：听到了，我们可以说话啦！
为什么需要三次握手？
是为了初始化 Sequence Number 的初始值。
握手 Q&A
首次握手的隐患—— SYN 超时
问题分析：
Server 收到Client的 SYN ， 回复 SUN-ACK 的时候未收到ACK的确认。
Server 不断重试直至超时，Linux 默认等待63秒(1+2+4+8+16+32)后才断开连接。
应对：
SYN 队列满后，通过 TCP_syncookies 参数回发 SYN Cookie。
若为正常连接则是 Client 回发 SYN Cookie， 直接建立连接。
建立连接的时候，Client出现故障
启动保活机制，向对方发送保活探测报文，如果未收到响应则继续发送。
尝试次数达到保活探测数 仍未 收到响应 则中断连接。
TCP 的四次挥手
挥手 即 终止连接
详细步骤：
挥手 Q&A
为什么会有 TIME_WAIT 状态？
确保有足够的时间让对方收到 ACK 包。
避免新旧连接混淆。
为什么需要四次挥手才能断开连接？
全双工，发送方和接收方都需要 FIN 报文和 ACK 报文。
为什么服务器会出现大量 CLOSE_WAIT 状态？
对方关闭 socket 连接，我方忙于读或写，没有及时关闭连接。
检查代码，尤其是释放资源的代码。
检查配置，尤其是处理请求的线程配置。（例：线程池中数字的配置不合理）
UDP
面向非连接。
不维护连接状态，支同时向多个客户端传输相同的消息。
数据包报头只有8个字节，额外开销较小。
吞吐量只受限于数据生成速率、传输速率以及机器性能。
尽最大努力交付，不保证可靠交付，不需要维持复杂的链接状态表。
面向报文，不对应用程序提交的报文信息进行拆分或者合并。
TCP 和 UDP 的区别
面向连接 VS 无连接
可靠性
有序性
速度
量级
TCP的滑动窗口
RTT 和 RTO：
RTT：发送一个数据包到收到对应的ACK，所花费的时间。
RTO：重传时间间隔。
流量控制与乱序重排：
保证 TCP 的可靠性
保证 TCP 的流控制性
窗口数据的计算过程：
EffectiveWindows(窗口内剩余数据大小) = AdvertiseWindow- (LastByteSend - LastByteAcked)
HTTP
支持客户/服务器模式
简单快速 (get post head)
灵活
无连接
无状态
请求/响应的步骤
客户端连接到 Web 服务器
发送 HTTP 请求
服务器接收请求并返回http响应
释放连接 TCP 连接 （keep alive）
客户端浏览器解析 HTML 内容
键入 URL，按下回车之后经历的流程
DNS 解析 → TCP 连接 → 发送 HTTP 请求 →
服务器处理请求并返回 HTTP 报文 → 浏览器解析渲染页面 → 连接结束
HTTP 状态码
1xx：指示信息 -- 请求已接收，继续处理。
2xx：成功 -- 请求已被成功接收、理解、接受。
3xx：重定向 -- 要完成请求必须进行更进一步的操作。
4xx：客户端错误 -- 请求有语法错误 或者 请求无法实现。
5xx：服务端错误 -- 服务器未能实现合法的请求。
GET 请求和 POST 请求的区别
HTTP报文层面： GET将请求信息放在URL（有长度限制），POST放在报文体中。
数据库层面：GET符合幂等性和安全性，POST不符合。
其他层面：GET可以被缓存、被存储，而POST不行。
Cookie 和 Session 的区别
Cookie 数据存放在客户的浏览器上，Session 数据放在服务器上。
Session 相对于 Cookie 更安全。
若考虑减轻服务器负担，应当使用 Cookie。
HTTPS
SSL（Security Sockets Layer 安全的套接层）
为网络通信提供安全及数据完整性的一种 安全协议。
是操作系统对外的 API，SSL3.0 后更名 TLS。
采用身份验证和数据加密保证 网络通信的安全和数据的完整性。
加密的方式
对称加密（易泄露）：加密和解密都使用同一个密钥。
非对称加密（性能低）：加密使用的密钥和解密使用的密钥是不相同的。
哈希算法：将 任意长度的信息转换成 固定长度的值 ， 算法不可逆。
数字签名：证明某个消息 或者 文件是某人发出/ 认同的。
HTTP 数据传输流程
浏览器将 支持的加密算法信息 发送给服务器。
服务器 选择一套浏览器支持的加密算法，以证书的形式回发浏览器。
浏览器 验证证书合法性，并结合证书公钥加密信息 发送给服务器。
服务器 使用私钥解密信息，验证哈希，加密响应消息 回发浏览器。
浏览器 加密响应消息，并对 消息进行验证，之后进行加密交互。
HTTP 和 HTTPS 的区别
HTTPS 需要到 CA 申请证书， HTTP不需要。
HTTPS 密文传输， HTTP 明文传输。
连接方式不同， HTTPS 默认使用 443端口， HTTP 使用 80 端口。
HTTPS = HTTP + 加密 + 认证 + 完整性保护 ， 较 HTTP更安全。
HTTPS不一定安全
浏览器默认填充的是 http:// ，请求需要进行跳转，在此期间 有被劫持的风险。
可以使用 HSTS （HTTP Strict Transport Security）进行优化。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
