【计算机网络】TCP/IP协议知识点总结

三次握手和四次挥手

三次握手

服务端：设置要实现什么功能
客户端：设置的东西的使用者，连接者

第一次握手序列号seq=x是随机产生的，第二次握手ack=x+1。因为 seq代表的是发送的数据的编号，ack是下一次发送数据的编号，简单理解就是在数据传送过程中，client端的seq告诉你我要发数据了发x个，server端发送的x+1是告诉对方，你发的x个数据包我都收到了（确认作用），下次就从x+1开始发吧。

1. 第一次握手：建立连接时，客户端发送syn包到服务器，并进入SYN-SENT状态，等待服务器确认；SYN：同步序列编号

2. 第二次握手：服务器收到syn包，必须确认客户的SYN，同时自己也发送一个SYN包，即SYN+ACK包，此时服务器进入SYN-RCVD状态；

3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

四次挥手

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，序列号seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态，TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1,并且带上自己的序列号seq=v,此时，服务端就进入了CLOSE_WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受，这个状态还要持续一段时间，也就是整个CLOSE _WAIT状态持续的时间。
3. 客户收到服务器的确认请求后，此时，客户端进入FIN-WAIT-2(终止等待2)状态，等待服务器发送链接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4. 服务器将最后的数据发送完毕后，就向客户端发送链接释放报文，FIN=1，ack=u+1,由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w,此时，服务器就进入了LAST_ACK(最后确认)状态，等待客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1,而自己的序列号是seq=u+1,此时客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2**MSL（最长报文段寿命）的时间后，党客户端撤销相应的TCB后，才进入CLOSED状态。
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态，同样，撤销了TCB后，就结束了这次的TCP连接，可以看到，服务器结束TCP连接的时间要比客户端早一些。

TCP连接常见面试题

1. 为什么连接的时候是三次握手，关闭的时候是四次握手？

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

2. 为什么TIME_WAIT状态需要经过2MSL（最大报文段生存时间）才能返回到CLOSED状态？

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可能最后一个ACK丢失，所以TIME_WAIT 状态就是用来重发可能丢失的ACK报文。在客户发送出最后的ACK回复，但该ACK可能丢失，服务端如果没有收到ACK，将不断重复发送FIN片段。所以客户端不能立即关闭，他必须确认服务端接收到了该ACK。客户端会在发送出ACK之后进入到TIME _WAIT状态。客户会设置一个计时器，等待2msl的时间，如果在该时间内再次收到FIN，那么客户端会重发ACK并再次等待2MSL时间。所谓的MSL(Maximum Segment Lifetime)是只一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果知道2MSL，客户端都没有再次收到FIN，那么客户端推断ACK已经被成功接收，则结束TCP连接。

3. 为什么不能用两次握手进行连接？

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作（双方都知道彼此已准备好），也要允许双方就出事序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

4. 如果已经建立了连接，但是客户端突然出现了故障怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

UDP和TCP协议

在TCP/UDP传输段中，源端口地址和目的端口地址是不能相同的，否则就会建立自己到自己的连接，白白耗费资源。

UDP协议

全称是用户数据报协议，在网络中它与TCP协议一样用于处理数据包，具有以下特点：

1. 面向无连接

不需要像TCP一样在发送数据前进行三次握手建立连接的，想发送数据就可以开始发送数据。具体来说即：

• 在发送端，应用层将数据传递给传输层的UDP协议，UDP只会给数据增加一个UDP投标识，然后就传递给网络层了。
• 在接受端，网络层将数据传递给传输层UDP只去除IP报文头就传递给应用层，不会任何拼接操作。

2. 有单播、多播、广播的功能

UDP不止支持一对一的传输方式，同样支持一对多、多对多、多对一的方式，也就是说UDP提供了单播、多播、广播的功能。

3. UDP是面向报文的

发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文

4. 不可靠性

• 首先体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠
• 并且受到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经确认正确接收到数据了。
• 网络环境时好时坏，但是UDP因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整，这样实现的弊端就是在网络条件不好的情况下可能会导致丢包

5. 头部开销小，传输数据报文时是很高效的

UDP的头部开销小，只有八字节，相比TCP的至少二十字节要少得多，在传输数据报文时是很高效的

• 优点：在某些实时性要求高的场景（比如电话会议）就需要使用UDP而不是TCP

TCP协议

1.面向连接

在发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”，这样能建立可靠的连接
2. 仅支持单播传输

每条TCP传输连接只能有两个端点，只能进行点对点的数据传输，不支持多播和广播的传输方式
3. 面向字节流

不像UDP一样那样一个个报文独立地传输，而是在不保留报文边界的情况下以字节流方式进行传输。
4. 可靠传输

判断丢包，误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接受端实体的包的按序接收，然后接受端实体对已成功收到的字节发回一个相应的确认（ACK）；如果发送端实体在合理的往返时延内未收到确认，那么对应的数据（假设丢失了）将会被重传
5. 提供拥塞控制

当网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞
6. 提供全双工通信

允许通信双方的应用程序在任何时候都能发送数据，因为TCP连接的两端都设有缓存，用来临时存放双向通信的数据。当然，TCP可以立即发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决于MSS）

为什么tcp可靠，哪些方法保证可靠

[1] 确认和重传机制
建立连接时三次握手同步双方的“序列号 + 确认号 + 窗口大小信息”，是确认重传、流控的基础

传输过程中，如果Checksum校验失败、丢包或延时，发送端重传。

[2] 数据排序

TCP有专门的序列号SN字段，可提供数据re-order

[3] 流量控制

滑动窗口和计时器的使用。TCP窗口中会指明双方能够发送接收的最大数据量，发送方通过维持一个发送滑动窗口来确保不会发生由于发送方报文发送太快接收方无法及时处理的问题。

[4] 拥塞控制

TCP的拥塞控制由4个核心算法组成：

“慢启动”（Slow Start）

“拥塞避免”（Congestion avoidance）

“快速重传 ”（Fast Retransmit）

“快速恢复”（Fast Recovery）

TCP的流量控制

滑动窗口机制：
滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。

发送和接受方都会维护一个数据帧的序列，这个序列被称作窗口。发送方的窗口大小由接受方确定，目的在于控制发送速度，以免接受方的缓存不够大，而导致溢出，同时控制流量也可以避免网络拥塞。图中的4,5,6号数据帧已经被发送出去，但是未收到关联的ACK，7,8,9帧则是等待发送。可以看出发送端的窗口大小为6，这是由接受端告知的（事实上必须考虑拥塞窗口cwnd，这里暂且考虑cwnd>rwnd）。此时如果发送端收到4号ACK，则窗口的左边缘向右收缩，窗口的右边缘则向右扩展，此时窗口就向前“滑动了”，即数据帧10也可以被发送。## 用户用浏览器访问一个网站的过程
1.用户在浏览器中输入网址，计算机提取出域名

2.浏览器通过DNS查找域名对应的IP地址，获得IP地址后

3.尝试与对应的服务器建立TCP连接，连接成功之后

4.将用户的请求装入http数据包，通过建立的tcp连接发送给服务器，等待数据返回。

5.如果数据成功返回，比如说，返回的是一个html页面，则渲染这个页面（可以理解为显示出来），渲染的过程中会遇到一些数据标记，比如图片，这时候就查找本地缓存，如果缓存里有且没过期，就使用本地缓存的数据，否则就向服务器发送请求

请你说一说TCP断连过程，以及单向连接关闭后还能否通信

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。四次挥手过程：
（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。

（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。

（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A。

（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。

四次挥手原因：这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

请你说说TCP和UDP用一个端口发送信息是否冲突

不冲突，TCP、UDP可以绑定同一端口来进行通信，许多协议已经这样做了，例如DNS适用于udp / 53和tcp / 53。因为数据接收时时根据五元组{传输协议，源IP，目的IP，源端口，目的端口}判断接受者的。

请你回答一下搜索敏感词汇时，页面被重置的原理

根据TCP协议的规定，用户和服务器建立连接需要三次握手：第一次握手用户向服务器发送SYN数据包发出请求（SYN, x:0），第二次握手服务器向用户发送SYN/ACK数据包发出回应（SYN/ACK, y:x+1），第三次握手用户向服务器发送ACK数据包发出确认（ACK, x+1:y+1），至此一个TCP连接建立成功。其中x为用户向服务器发送的序列号，y为服务器向用户发送的序列号。
关键字检测，针对明文或者base64等弱加密通讯内容，与准备好的敏感词库进行匹配，当发现敏感词时，将服务器发回的SYN/ACK包改成SYN/ACK, Y:0，这代表TCP连接被重置，用户便主动放弃了连接，提示连接失败。让用户误认为服务器拒绝连接，而主动放弃继续与服务器连接，自动阻断记录含有敏感词的网页

解析DNS的具体过程

DNS( Domain Name System)是”域名系统“的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，用于TCP/IP网络。所提供的服务是用来将主机名和域名转换为IP地址的工作。

1. 浏览器缓存
   当用户通过浏览器访问某域名时，浏览器首先会在自己的缓存中查找是否有该域名对应的IP地址（若曾经访问过该域名且没有清空缓存便存在）
2. 系统缓存
   当浏览器缓存中无域名对应IP则会自动检查用户计算机系统Hosts文件DNS缓存是否有该域名对应IP；
   • hosts文件：Hosts是一个没有扩展名的系统文件，可以用记事本等工具打开，其作用就是将一些常用的网址域名与其对应的IP地址建立一个关联“数据库”
3. 路由器缓存
   当浏览器及系统缓存中均无域名对应IP则进入路由器缓存中检查，以上三步均为客户端的DNS缓存
4. ISP（互联网服务提供商）DNS缓存
   当在用户客户端查找不到域名对应IP地址，则将进入ISP DNS缓存中进行查询。比如你用的是电信的网络，则会进入电信的DNS缓存服务器中进行查找
5. 根域名服务器
   当以上均未完成，则进入根服务器进行查询。全球仅有13台根域名服务器，1个主根域名服务器，其余均为辅跟域名服务器。根域名收到请求后会查看区域文件记录，若无则将其管辖范围内顶级域名服务器IP告诉本地服务器
6. 顶级域名服务器
   顶级域名服务器收到请求后查看区域文件记录，若无则将其管辖范围内主域名服务器的IP地址告诉本地DNS服务器；
7. 主域名服务器
   主域名服务器接受到请求后查询自己的缓存，如果没有则进入下一级域名服务器进行查找，并重复该步骤直至找到正确纪录；
8. 保存结果至缓存
   本地域名服务器把返回的结果保存到缓存，以备下一次使用，同时将该结果反馈给客户端，客户端通过这个IP地址与web服务器建立链接。

从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是的交互查询就是迭代查询。

• 迭代查询

迭代查询又称重指引，当服务器使用迭代查询时能使其他服务器返回一个最佳的查询点提示或主机地址，若此最佳的查询点中包含需要查询的主机地址，则返回主机地址信息，若此时服务器不能够直接查询到主机地址，则是按照提示的指引依次查询，直到服务器给出的提示中包含所需要查询的主机地址为止，一般每次指引都会更靠近根服务器（向上），查寻到根域名服务器后，则会再次根据提示向下查找。

• 递归查询

递归查询是最常见的查询方式，域名服务器将代替提出请求的客户机（下级DNS服务器）进行域名查询，若域名服务器不能直接回答，则域名服务器会在域各树中的各分支的上下进行递归查询，最终将返回查询结果给客户机，在域名服务器查询期间，客户机将完全处于等待状态。示例： （红色为查询，蓝色为迭代查询返回的提示信息，棕色为递归查询返回的IP信息）

示 例说明：A向B发送递归查询请求，B向C发送迭代查询请求（下一节将介绍迭代查询），得到C给出的提示后，B向D发送迭代查询请求，得到D给出的提示后， B向E发出迭代请求，得到E给出的提示后，B向F发出迭代查询请求，得到F给出的提示后，B得到了F返回G的IP地址，B向A返回G的IP地址，整个查询结束。

说明：假设你要寻找一家你从未去过的公司，你会有2种解决方案，1是找一个人替你问路，那可能是你的助手，2是自己问路，每走过一个路口，就问一个人，这就好比递归查询和迭代查询，递归查询在这里代表你的第1种解决方案，而迭代则是第2种解决方案。