标签：发送 ACK 报文 TCP 计算机网络 面试 服务器 连接

一、问题

1、分层
2、TCP
2.1 三次握手与四次挥手
2.2 TCP-可靠传输
2.3 TCP其他

3、HTTP
4、DNS解析
5、URL-浏览器显示

6、其他
1）RPC
2）SOCKET

二、具体

1、OSI七层网络模型（*4）

OSI七层	作用	对应网络协议	TCP/IP四层	对应软硬件
应用层（Application）	为应用程序提供网络服务	HTTP、TFTP、FTP、NFS、WAIS、SMTP	应用层	应用程序
表示层（Presentation）	数据格式化，加密、解密	Talnet、Rlogin、SNMP、Gopher
会话层（Session）	建立、维护、管理会话连接	SMTP、DNS
传输层（Transport）	建立、维护、管理端到端连接	TCP、UDP	传输层	操作系统
网络层（Network）	IP寻址和路由选择	IP、ICMP、ARP、RARP、AKP、UUCP	网络层
数据链路层（Data Link）	控制网络层和物理层之间通信	FDDI、Ethernet、Arpanet、PDN、SLIP、PPP	数据链路层（可不合并物理层）	设备驱动程序与网络接口
物理层（Physical）	比特流传输	IEEE 802.1A、IEEE 802.2到IEEE 802.11

追问1：为什么有了七层还有五层的概念?

统一网络需要一个统一标准，ISO开始制定了OSI模型，清晰易懂，大家觉得OSI 会成为统一标准，于是用OSI结构理论作为术语交流。但后来TCP/IP协议诞生发展繁荣，而OSI迟迟没有成熟产品推出，妨碍第三方厂家开发软硬件，从而影响至今。

2、TCP三次握手与四次挥手具体过程

2.1、三次握手（Three-way Handshake）过程

• 注意：下图要达到熟练默写程度。
  

补充：x = client_isn； y = server_isn； z = client_isn+1

追问1：为什么两次握手不行？

三次握手是为了让双方验证各自接收能力和发送能力。

• 1st：A发送SYN给B，B接收到。这里B能确认A的发送能力和B的接收能力。
• 2nd：B发送SYNACK给A，A收到。这里A能确认A的接收能力和B的发送能力。此外，A收到SYNACK，说明前面A的SYN成功到达B，也能确认A自己的发送能力和B的接收能力。至此，A已经确认双方各自发送能力和接收能力OK，因此转为ESTABLISHED状态。
• 3rd：A发送ACK到B，B接收。这里B能确认A的发送能力和B的接收能力。由于B能收到ACK，说明前面发送的SYNACK已经被接受了，说明A的接收能力和B的发送能力正常。

若使用两次握手，就不能确认上述四种能力，可能有问题。

• 假定A发的SYN报文没消失，而是在某网络节点长时间滞留了，以至于到连接释放后的某个时间才到达B。

• 本来这是一个早已失效的报文段，但B收到此失效连接请求报文段后，却误以为是A又发出一次新的连接请求，于是A就发出确认报文段，同时建立连接。

• 由于现在A并没有发出建立连接请求，因此不理睬B的SYNACK报文，也不会向B发送数据，但B却以为新连接已经建立，并一直等待A发来的数据，B的许多资源被白白浪费。

追问2：三次握手过程中可以携带数据吗？

前两次不行，第三次可以携带。

追问3：为什么？

假如第一次可以，如果有人恶意攻击服务器，那他在第一次SYN 报文中放入大量数据。因为攻击者根本不理会服务器的接收、发送能力是否正常，只是疯狂重复发 SYN 报文，这会让服务器花费很多内存与时间来接收这些报文。
也就是说，第一次握手不能放数据，1个简单原因服务器会更容易受到攻击。而对于第三次，此时客户端处于 ESTABLISHED 状态，已经建立起连接，知道服务器接收与发送能力正常，所以携带数据也没毛病。

追问4：ISN（Initial Sequence Number）是固定的吗？

不固定，client_isn是随机生成的，而server_isn则需要根据SYN报文中的源、IP和端口，加上服务器本身密码数进行相同散列得到，显然也不固定。

追问4：第三次握手失败了怎么办？

1. 在第2次握手中，server向client发送SYN+ACK报文后，就会启动一个定时器，等待client返回的ACK报文。
2. 如果第三次失败，client给server返回了ACK报文，server并不能收到这个ACK报文。那server就会启动超时重传机制，超过规定时间会重新发起第2次握手，向client发送SYNACK。重传次数默认5次。
3. 如果到重传指定次数，仍未收到ACK应答，那一段时间后server会关闭这个连接。但client认为这个连接已建立，如果它向server写数据，server将回应RST包、强制关闭TCP连接，以防止SYN攻击。

追问5：什么是SYN攻击？如何防范？

在三次握手过程中，服务器发送SYN-ACK之后，收到客户端ACK之前的TCP连接称为半连接（half-open connect）。此时服务器处于SYN-RECV。当收到ACK后，服务器转入ESTABLISHED状态。

SYN攻击就是攻击客户端，在短时间内伪造大量不存在的IP地址，向服务器不断发送SYN包，服务器回复确认包，并等待客户确认。 由于源地址不存在，服务器需要不断重发直至超时，这些伪造SYN包将长时间占用未连接队列，正常SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。

SYN攻击是一种典型的DoSe/DDoS攻击。

追问6：如何检测SYN攻击？

检测SYN攻击非常方便，当你在服务器上看到大量半连接状态时，特别是IP地址是随机的，基本可以断定这是一次SYN攻击，在Linux/Unix可用netstat命令检测。

追问7：如何防御SYN攻击？

SYN攻击不能完全被阻止，除非重新设计TCP协议。能做的就是就是尽可能减轻SYN攻击危害，常见防御方法有：缩短超时（SYN Timeout）时间、增大最大半连接数、过滤网关防护、SYN cookies技术。

追问8：服务器为什么使用特殊的初始序号server_isn？

服务器使用特定初始序列号server_isn（从源和目的地IP和端口的散列中获取） 可以用来抵御SYN洪水攻击。

追问9、握手过程中除了序号的同步，还会同步什么信息？

补充：发数据时应注意TCP连接哪些信息，如客户端怎么知道该给服务端发送1个还是10个报文？

• 1）序号；
• 2）标志位：SYN（发起一个连接）、ACK（确认序号有效）；
• 3）窗口（流量控制中的接收？）。
  

2.2、 四次挥手（four-way handshake）过程

Client或Server均可主动发起。在socket编程中，执行close()操作即可产生挥手操作。

• 1st： 先由Client向Server发送 1 个FIN报文，用来关闭Client到Server的数据传送；
• 2nd： 当Server收到Client的FIN时，会回复一个ACK，其中ACK值=FIN+SEQ；
• 3rd： 然后Server向Client发送一个FIN，用来关闭Server到Client的数据传送；
• 4th： 当Client收到Server的FIN时，回复 1 个ACK给Server，其中ACK值=FIN+SEQ。

追问1：为什么建立连接是三次握手，而关闭连接却是四次挥手呢？（*2）

关键在中间两步：

• 这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
• 而关闭连接时，收到对方的FIN报文时，仅表示对方不再发送，但还能接收数据，己方也未必全部发送完毕。
  所以只能先回复一个ACK报文，告诉客户端“你发的FIN报文已收到”。等服务器所有报文发送/接收完，才能发送FIN报文。因此ACK和SYN分开发送，要四次握手。

追问2：为什么会有第二次、第三次、第四次挥手？(*2)

确保数据能完整传输。

1. 当服务器收到客户端的FIN报文通知时，它仅仅表示客户端没有数据再发送给服务器了。
2. 当服务器未将所有数据都发给了主动方，所以服务器不会马上关闭SOCKET，可能还需要发完数据后，再发FIN给主动方，表示同意关闭连接。

所以这里ACK报文和FIN报文大多数情况下是分开发送。

追问3：四次挥手释放连接时，等待2MSL的意义？（*2）

1. 保证客户端发送的最后1个ACK报文能到达服务器。假设网络不可靠，ACK报文丢失。如果服务端发出FIN报文后没收到ACK报文，就会重发FIN报文（收到不再发），此时处于TIME-WAIT的客户端就会重发ACK报文。
   当然，客户端也不能无限等待这个FIN报文，需要设置一个定时器，2MSL正好，因为1个最大发送和1个回复最长时间没收到ACK，可以推断ACK报文已经被服务器接收，所以结束TCP连接。

2. 防止已失效的连接请求报文段出现在新连接中。客户端发完最后1个ACK报文后，再经过2MSL时间，就可以使网络不通畅产生的滞留报文段失效，这样下一个新连接中就不会出现旧的连接请求报文。

补充：

MSL—Maximum Segment Lifetime，指报文在网络中最大存活时间，2MSL就是1个发送和1个回复所需最大时间。

追问4：为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态？

理论上，四个报文都发送完毕，就可以直接进入CLOSE状态。但网络如果不可靠，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

追问5：四次挥手过程中服务端的哪几种状态，哪几种包？

1. 收到FIN之前是ESTABLISHED状态；
2. 发完ACK过程变为CLOSE_WAIT（关闭等待） 状态；
3. 发完FIN报文后是LAST_ACK（最后确认） 状态；
4. 收到客户端ACK报文后变为CLOSED状态。

2.3、TCP可靠传输

1、TCP 可靠性如何保证？（*3）（机制）

1. 信道可靠：用三次握手、四次挥手保证连接正确；
2. 数据正确：分区编号&&校验和、超时重传；
3. 传输控制：流量控制、拥塞控制。

2、超时重传

TCP可靠传输方式是序列号与确认应答。当传送数据包丢失时，会用重传机制解决。常见重传机制有超时重传、快速重传、SACK、D-SACK。

超时重传是超过指定时间没收到对方ACK，就重发数据。解决丢失问题。
快速重传是以数据为驱动，收到三次同样ACK，就重发数据。解决时间问题。
SACK是收到三次同样ACK，触发快速重传机制，通告SACK字段发现丢失信息，然后只重传丢失部分。解决重传什么问题。
D-SACK只使用SACK告诉发送方哪些数据被重发接收了。可以确定哪方丢包，是否因为网络延迟。解决定位问题。

追问1：TCP非超时的情况下可能会重传吗？

会。快速重传协议中，发送报文1、2、3、4、5，2丢失，其他正常，定时器过期前收到三个ACK，会触发重传机制。

3、滑动窗口协议（*3）

滑动窗口协议可以连续发送数据，相比停止-等待协议，提高了信道利用率，加快数据传输。TCP窗口是连续发送的数据包起来的窗口，实际是操作系统开辟的缓存空间。发送端的窗口大小可以根据接收端处理能力来发送数据，动态调整，发送窗口大小约等于接收端口大小。

4、流量控制?（*3）

发送方无脑发，接收方处理不了，会触发重传机制，导致网络流量浪费。而流量控制可以让发送方根据接收方的实际接收能力控制发送数据量。

追问1：窗口关闭是什么？怎么解决？

现象：接收方处理完数据，窗口增大，然后通告窗口大小给发送方的ACK丢失，导致双方持续等待，成了死锁的现象。
解决：TCP连接方收到零窗口通知就启动计时器，发送窗口探测报文。探测时，若接收窗口仍为0，那接收报文一方就重新启动计时器；若不是0，死锁局面打破。

补充：窗口探测次数一般为3次，每次30-60s（不同实现可能不同）。
      如果3次接收窗口还是0，有的TCP就会发RST报文中断连接。

追问2：糊涂窗口综合征是什么？怎么解决？

接收方腾出几个字节告诉发送方窗口大小，而发送方会义无反顾发送这几个字节，导致报文利用率很低，这就是糊涂窗口综合征。

解决方式：

1. 让接收方不通告小窗口给发送方，
   If 窗口大小 < min{MSS，缓存空间/2}， Then 窗口为0；
   If 窗口大小>=MSS 或 接收方缓存空间/2 可用， Then 打开窗口。
2. 让发送方避免发小数据—延时处理。
   If（等到窗口大小 >= MSS 或 数据大小>= MSS） && 收到之前数据ACK回包；Then 发数据。

5、拥塞控制（*5）

拥塞控制是为了避免发送方数据填满整个网络。主要分为四个过程：

• S1. 慢启动：If cwnd < ssthresh，Then 指数增长；
• S2. 拥塞避免：If cwnd >= ssthresh，Then 线性增长；
• S3-1. 快速重传：If 超时重传，Then ssthresh = crwd/2， cwnd=1；
• S3-2、快速恢复：If 超时重传，Then ssthresh =crwd = crwd/2，[crwd = crwd + 3]。

追问1：流量控制和拥塞避免有何区别？

1. 流量控制是点对点，一对一，若接收方来不及接收，就直接找到发送方；
2. 拥塞控制是多（发送方）对一（接收方），若网络拥堵，发送方迟迟到不了，接收方找不到具体发送方。
3. 简单理解：拥塞控制是路上堵车，流量控制是停车场车位不够。

2.4、其他

1、TCP 和 UDP 区别（*5）

角度	TCP	UDP
连接	面向连接	无连接（发数据前不建立连接）
可靠性	可靠，使用流量和拥塞控制	不可靠，尽最大努力到达
连接对象	只能一对一通信	支持m：n四种通信，m>=1, n>=1
传输方式	面向字节流	面向报文
首部开销	20<=首部字节数<=60	首部开销小，仅8字节

追问1：适用场景（*3），哪些应用层协议使用了（*2）

	TCP	UDP
使用场景	效率要求低，准确性或有连接要求 如远程登陆、邮件传输	对效率要求高，准确性要求低。 如实时应用， IP电话、视频、直播等.
应用层协议	SMTP-电子邮件 TELNET-远程登录 HTTP-万维网 FTP-文件传输 IP-Internet协议（IP） ICMP-Internet控制信息 POP、SMTP-邮件传输	DNS-域名传输 TFTP-文件传输 SNMP-网络管理 NFS-远程文件服务器

2、TCP是面向连接的，这个连接具体指的是什么？

三次握手。（建立连接后，超时传输、排序、发生窗口、窗口大小，保证可靠性。）

3、通过什么方式去知道某台电脑上还能建立多少个TCP连接？

系统用四元组{Local IP，Local Port，Remote IP，Remote Port} 来唯一标识TCP连接。

Client发起TCP连接时，系统通常会选取一个空闲本地端口（Local Port），该端口，类型是Unsigned short，最大65536，端口0有特殊含义，因此最大可用端口，即最大TCP连接数只有65535。

Server部分的Remote IP和Remote Port可变，因此最大TCP连接为客户端IP数*客户端Port数，IPV4简单情况（不考虑地址分类）最大连接数为 2 32 2^{32} 232（IP数）* 2 16 2^{16} 216（Port数），也就是Server端单机最大TCP连接数约为 2 48 2^{48} 248。

netstat -ant | grep ……  # 查看TCP连接状态

4、TCP和IP区别。说下IP的包头和TCP的包头。

……

3、HTTP

1、Http简介

超文本传输协议（HTTP）是一个用于传输超媒体文档（如HTML）的应用层协议。是为Web浏览器和Web服务器之间通信而设计的，但也可用于其他目的。

2、HTTP与TCP

HTTP协议属于应用层，建立在传输层协议TCP之上，发送HTTP请求于接收HTTP响应都通过Socket接口来调用TCP协议实现。

如图，反映了一次HTTP请求并接收一个HTML文件过程与时间消耗（RTT），客户端通过TCP连接发送请求报文，服务器收到请求后向其传输文件并返回响应报文。

二、状态码

1、小结

HTTP状态码是当客户端向服务器端发送请求时，描述返回请求结果。

状态码	类别	原因短语
1XX	Informational（信息性状态码）	接收请求正在处理
2XX	Success	请求正常处理完毕
3XX	Redirection	需要进行附加操作完成请求
4XX	Cient Error	服务器无法处理请求
5XX	Server Error	服务器处理请求错误

2、展开

总	分	简短	阐述
2XX		成功
	200	OK	表示从客户端发来请求在服务端被正常处理
	204	No Content	请求处理成功，但没有资源可返回。如浏览器页面不发生更新。
	206	Partial Content	服务器成功执行客户端的部分资源请求。 相应报文包含由Content-Range指定范围实体内容。
3XX		重定向	响应结果表明浏览器需要执行某些特殊的处理以正确处理请求
	301	Moved Permanently	永久性重定向。资源URI已更新，你也更新下你的书签引用吧。
	302	Found	临时性重定向。资源URI已临时定位到其他位置，姑且算你已知道这个情况了
	303	See Other	与302类似，但一般表示客户端应采用GET方法获取资源。与302有区别。
	304	Not Modified	资源已找到，但未符合条件请求。
	307	Temporary Redirect	与302含义相同。尽管302禁止POST变换成GET，但实际使用并不遵守。
4XX		客户端错误
	400	Bad Request	我无法理解这个请求，是不是错了。 （请求报文存在语法错误，浏览器会像200 OK一样对待该状态码）
	401	Unauthorized	表示发送请求需要有通过HTTP认证（BASIC认证、DIGEST认证）。之前若已进行1次请求，则表示用户认证失败。
	403	Forbidden	不允许访问那个资源啊
	404	Not Found	服务器没请求资源，也可以是服务器拒绝请求且不想说明理由时使用。
5XX		服务器错误
	500	Internal Server Error	貌似，内部资源出故障了……（服务器端执行请求发生错误，也可能Web应用存在bug或临时故障）。
	503	Service Unavailable	抱歉，现在我正忙着（服务器暂时处于超负荷或正停机维护，无法处理请求）

401 VS 403
401—Unauthenticated，没有带认证信息或者认证信息错误；
403—Forbidden，带了正确认证信息，但服务器认为这个认证信息对应用户没有对应资源访问权限。

注意：状态码和状况的不一致：不少返回状态码是错误的，但用户可能察觉不到，比如Web应用内部发生错误，状态码仍然返回200 OK。

3、HTTP

1、HTTP1.1、HTTP2改进。

1. HTTP1.0 VS HTTP1.1

HTTP1.1引入更多缓存控制策略；引入range头域，方便自由选择资源，以便重复利用带宽与连接；支持Host头域；支持长连接和请求流水线处理。

HTTP1.0只使用较简单网页和网络请求，HTTP1.1则在1996年才开始广泛应用于各大浏览器。

2. HTTP1.X VS HTTP 2.0
   HTTP2.0采用新二进制格式，实现方便且健壮；每个request用作连接共享；双方各自cache一份header fields表，压缩了header 。

2、HTTPS

含义：运行在SSL/TLS，运行在TCP上，传输内容经过加密。

补充：HTTP　VS　HTTPS
1、HTTP传输内容是明文，HTTPS是密文。
2、HTTP和HTTPS使用完全不同的连接方式，端口不同，前者是80，后者是443.

追问１：用到了哪种密钥？

Https密钥有对称密钥和非对称密钥。

补充: 里面知识点不多，但过程相对复杂.
      基本上就是有数字证书，然后把对称密钥作为消息，非对称密钥进行传输。双方通信通过对称密钥进行解密。

3、Cookie和Session的区别，怎么防止Cookie欺骗

• Cookie是由服务器生成发送给浏览器，保存在本地的数据，方便下一次发送给服务器。
• Session是用户与Web服务器交互时产生session；session包含用户临时信息保存在服务器，用户离开网站被销毁。
• 建议：将登陆信息放在session，其他信息需要保留可以放在cookie。

项	Cookie	Session
存储位置	客户浏览器	服务器
安全性	不太安全，可被分析cookie欺骗服务器	更安全
性能	可减轻服务器负担	影响服务器性能
数量	很多浏览器都限制一个站点最多保存20个cookie	单个cookie保存数量不能超过4K

4、http的长链接和短连接？

项	短(非持久)连接	长(持久)连接
含义	客户端和服务端建立连接，送完数据立马断开。下次取数据要再建立连接。	客户端和服务端建立连接后不断开，之后客户端再访问这个服务器内容，继续使用这条连接通道。
过程	连接->传输数据->关闭连接	连接->传输数据->保持连接 -> 传输数据-> …->关闭连接，多是客户端关闭。
场景	并发量大但无需频繁操作的情况。	长连接适用于频繁请求资源的客户。
协议	HTTP1.0默认	HTTP1.1默认

4、DNS解析

0. 浏览器缓存、本地hosts文件是否有IP地址。
1. client向本地DNS服务器（LDNS）发起请求。
2. LDNS服务器向DNS根服务器发送解析请求。
3. 根域名服务器返回gLTD服务器地址。

gTLD：国内顶级域名服务器，如.com、.cn、.org等。

4. 本地DNS服务器向gTLD服务器发起请求。
5. gTLD服务器并返回Name Server服务器地址。
6. 本地DNS服务器向Name Server服务器发送解析请求。
7. Name Server服务器返回IP地址给本地DNS服务器。
8. 本地DNS服务器返回IP地址给client，并缓存结果。
9. 浏览器缓存IP地址。
   

5、URL-浏览器显示

1、URL输入到浏览器输出页面过程

1. DNS域名解析；
2. ARP协议获得IP对应MAC地址（物理机器）；
3. 建立TCP连接；
4. 发送HTTP请求；
5. 服务器处理请求；
6. 返回响应结果；
7. 关闭TCP连接；
8. 浏览器解析HTML；
9. 浏览器布局渲染。

2、浏览器渲染过程
10. 解析HTML生成DOM树。
11. 解析CSS生成CSSOM规则树。
12. 将DOM树与CSSOM规则树合并在一起生成渲染树。
13. 遍历渲染树开始布局，计算每个节点的位置大小信息。
14. 将渲染树每个节点绘制到屏幕。

6、其他

1）RPC
2）SOCKET

三、参考

1、【计网】TCP三次握手与四次挥手详解
2、【计网】TCP可靠传输
3、【计网】TCP VS UDP
4、【计网】DNS解析过程
5、【计网】HTTP详解
6、【计网】从输入URL到浏览器渲染页面

标签：发送,ACK,报文,TCP,计算机网络,面试,服务器,连接
来源： https://blog.csdn.net/HeavenDan/article/details/115265272

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。