本文共 5375 字，大约阅读时间需要 17 分钟。

一、 网络基础知识讲解

1.1 OSI 开放式互联参考模型

1.2 OSI 的“实现”：TCP/IP

OSI七层模型	TCP/IP概念层模型	功能	TCP/IP协议族
应用层	应用层	文件传输，电子邮件，文件服务，虚拟终端	TFTP,BTTP,SNMP,FTP
表示层		数据格式化，代码转换，数据加密	—
会话层		解除或建立与别的节点的联系	—
传输层	传输层	提供端对端的接口	TCP, UDP
网络层	网络层	为数据包选择路由	IP, ICMP
数据链路层	链路层	传输地址的帧及错误检测功能	SLIP,PPPM, MTU
物理层		以二级制数据形式在物理媒体上传输数据	ISO2110,IEEE802

二、TCP的三次握手

2.1 传输控制协议 TCP 简介

• 面向连接的、可靠的、基于字节流的传输层通信协议。
• 将应用层的数据流分割成报文段并发送给目标节点的 TCP 层。
• 数据包都有序号，对方收到则发送 ACK 确认，未收到则重传 。
• 使用校验和来检验数据在传输过程中是否有误。

2.2 TCP 报文头

一般使用IP+协议+端口号（Socket套接字）标识网络中的一个进程

2.3 TCP Flags

1. URG：紧急指针标志
2. ACK：确认序号标志
3. PSH：push 标志
4. RST：重置连接标志
5. SYN：同步序号，用于建立连接过程
6. FIN：finish 标志，用于释放连接

2.4 三次握手流程

SYN -->Synchronize Sequence Numbers--> 同步队列编号 ACK -->Acknowledge character---------> 确认字符

第几次握手	SYN	ACK	seq	ack	内容
第一次握手	1	-	j	-	客户端发送 SYN 包(syn=j)到服务器，并进入 SYN_SEND 等待状态，等待服务器确认；
第二次握手	1	1	k	j+1	服务器收到 SYN 包，必须确认客户的 SYN(ack=j+1)，同时自己也发送一个 SYN包(syn=k)，即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态；
第三次握手	-	1	k	k+1	客户端收到服务器的 SYN+ACK 包，向服务器发送确认 ACK(ack=k+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED 状态，完成三次握手。

2.5 三次握手的主要作用是？

• 确认双方接受，发送能力是否正常
• 指定自己的初始化序列号，为后面的可靠传输做准备
• 如或是HTTPS，还要进行数字证书验证和加密密匙生成
  当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。 三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

2.6 为什么要三次握手才能建立连接？

• 第一次握手：客户端发送网络包，服务端收到了。
  这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
• 第二次握手：服务端发包，客户端收到了。
  这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
• 第三次握手：客户端发包，服务端收到了。
  这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常

试想如果是用两次握手，则会出现下面这种情况：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

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

问题起因分析

• Server 收到 Client 的 SYN，回复 SYN-ACK 的时候未收到 ACK 确认。
• Server 不断重试直至超时，Linux 默认等待63(1+2+4+8+16+32)秒才断开连接。

针对SYN Flood 的防护措施（伪造不存在的ip进行SYN发送，使其占用大量半连接队列）

• 缩短超时（SYN Timeout）时间
• 增加最大半连接数
• 过滤网关防护
• SYN cookies技术
  SYN 队列满后，通过 tcp_syncookies 参数回发 SYN Cookie。
  若为正常连接则 Client 会回发 SYN Cookie ，直接建立连接。

三、 TCP 的四次挥手

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

3.1 为什么一定要四次挥手，不能三次，把中间两次放在一起？

• 因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。*
• 但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

3.2 为什么会有 TIME_WAIT 状态

1. 保证客户端发送的最后一个ACK报文段能够到达服务端。

   这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，服务端超时重传FIN+ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，若客户端在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。

2. 防止“已失效的连接请求报文段”出现在本连接中。

   客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

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

对方关闭 socket 连接，我方忙于读或写，没有及时关闭连接

• 检查代码，特别是释放资源的代码。
• 检查配置，特别是处理请求的线程配置。

四、 TCP 和 UDP 的区别

4.1 UDP简介

UDP结构

UDP特点

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

4.2 TCP和UDP的区别

-	TCP	UDP
是否连接	面向连接	无连接
是否可靠	可靠传输，使用流量控制和拥塞控制	不可靠传输，不使用流量控制和拥塞控制
连接对象个数	只能一对一通信	支持一对一，一对多，多对一和多对多通信
传输方式	面向字节流	面向报文
首部开销	首部最小20字节，最大60字节	小，仅8字节
适用场景	要求可靠传输的应用，例如文件传输	适用于实时应用，例如视频会议，视频直播

五、 TCP 的滑动窗口

RTT 和 RTO

• RTT：发送一个数据包到收到对应的 ACK，所花费的时间。
• RTO：重传时间间隔。
  TCP 使用滑动窗口做流量控制与乱序重排
• 保证 TCP 的可靠性。
• 保证 TCP 的流控特性。

六、 HTTP 相关

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

• 支持客户/服务器模式（C/S）.
• 简单快速
• 灵活
• 无连接
• 无状态

6.2 http请求结构

6.3 http响应结构

6.3请求/响应的步骤

1. 客户端连接到 WEB 服务器
2. 发送 HTTP 请求
3. 服务器接受请求并返回 HTTP 响应
4. 释放连接 TCP 连接
5. 客户端浏览器解析 HTML 内容

6.4 在浏览器地址栏键入 URL，按下回车后经历的流程

1. DNS 解析
2. TCP 连接
3. 发送 HTTP 请求
4. 服务器处理请求并返回 HTTP 报文
5. 浏览器解析渲染页面
6. 连接结束

6.5 HTTP 状态码

1XX：指示信息——表示请求已接受，继续处理。2XX：成功——表示请求已被成功接收、理解、接受。200 OK：正常返回信息。3XX：重定向——要完成请求必须进行更进一步的操作。301 Moved Permanently：永久重定向。302 Found：临时跳转。4XX：客户端错误——请求有语法错误或请求无法实现。400 Bad Request：客户端请求有语法错误，不能被服务器所理解。401 Unauthorized：请求未经授权。403 Forbidden：服务器收到请求，但是拒绝提供服务。404 Not Found：请求资源不存在。5XX：服务器端错误——服务器未能实现合法的请求。500 Internal Server Error：服务器发生了不可预期的错误。503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常。

6.6 GET 请求和 POST 请求的区别

1. HTTP 报文层面：GET 将请求放在 URL，POST 放在报文体中。
2. 数据库层面：GET 符合幂等性和安全性，POST 不符合。
3. 其他层面：GET 可以被缓存、被存储，而 POST 不行。

6.7 Cookie 和 Session 的区别

Cookie 简介

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

Cookie 的设置以及发送过程

Session 简介

• 服务器端的机制,在服务器上保存信息。
• 解析客户端请求并操作session id,按需保存状态信息。

Session的实现方式

• 使用Cookie来实现。
• 使用URL回写来实现。

Cookie和Session的区别

• Cookie数据存放在客户的浏览器上,Session数据放在服务器上;
• Session相当于Cookie更安全;
• 若考虑减轻服务器负担可以考虑使用Cookie;

七、 HTTP和HTTPS的区别

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

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

HTTPS数据传输流程

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

HTTP和HTTPS的区别

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

HTTPS不一定安全

• 浏览器默认填充 http:// 请求需要跳转有被劫持的风险;
• 可以使用HSTS优化;

八、 Socket 相关

转载地址：http://uxjwi.baihongyu.com/