计算机网络技术

一、计算机网络OSI七层协议

OSI七层协议	作用	代表
应用层	规定应用程序的数据格式，为应用程序提供数据交互服务	Http协议（网页）、FTP协议（文件传输）、SMTP协议（电子邮件）、DNS协议（域名转换）
表示层	负责将原有的数据格式转换成网络标准数据格式，如加密解密、转换翻译、压缩解压缩等；能够接收不同的信息，如文字流、图像、声音等；	属于广义应用层的一部分
会话层	负责在网络中的两个节点间建立、维持和终止通信。比如服务器验证用户登录，就是由会话层完成的。	属于广义应用层的一部分
传输层	向主机进程提供通用的数据传输服务，建立端口与端口之间的连接。 进程间通信需要双方的IP地址、端口号与通信采用的协议栈。主机 + 端口 = 套接字	TCP协议、UDP协议
网络层	根据IP地址选择合适的路由与交换节点，建立主机到主机之间的通信。 网络层通过区分两个主机的MAC地址是否属于同一个子网，来判断采用广播的方式还是路由的方式。  若是同一个子网就采用广播的方式，若不是则采用路由的方式发送。而网络层的作用就是引入一套新的地址，使得我们能区分哪些计算机属于同一个子网，这个机制就被称为IP地址。	IP协议 (MAC地址 + IP协议 )
数据链路层	链路层就是规定了0和1的分组方式。 计算机传输是以0和1的形式传输的，单纯的0和1没有任何意义。必须规定解读方式：多少个电信号算一组？每个信号位有什么含义？	以太网
物理层	在两个不同局域网（移动，联通）通信，把电脑连接起来的物理手段，可以用光缆、电缆、双绞线、无线电波等形式，它主要规定了网络的一些电器特性，作用是负责传送0和1的电信号	光缆、电缆、双绞线、无线电波

---

二、TCP和UDP的区别？

	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠	可靠
是否有序	无序	有序
传输速度	快	慢
连接对象	支持【一对一、一对多、多对一、多对多】交互通信	只能【一对一】通信
首部开销	首部开销小，仅8字节	首部开销至少20字节，最大60字节
应用场景	适用于实时通信（IP电话、视频会议、直播等），以及DNS(域名转换) / SNMP(网络管理)	适用于要求可靠传输的应用，例如文件传输FTP协议、Http/Https协议

---

三、TCP三次握手过程

阶段	客户端	服务端	作用
初始状态	客户端处于关闭状态	服务端监听某个端口，处于Listen状态	×
第一次握手	客户端发起TCP连接请求，向服务端发送同步报文(SYN = 1)，同时发送初始序列号seq = x。进入syn_sent状态，等待服务端确认。		服务端收到客户端的报文。【服务端】可以知道：客户端的发送能力ok，服务端本身的接收能力ok。
第二次握手		服务端收到客户端发送的SYN报文信息，也随机发送一个初始序列号seq = y，并回复ack = x + 1，表示收到了客户端序列号x之前的数据，希望下次客户端从序列号x+1开始发送报文。同时，设置SYN = 1 和ACK = 1；表示这是一个SYN握手和ACK确认应答报文。然后服务端进入syn_reviced状态。	客户端收到服务端的报文。【客户端】可以知道：客户端本身的发送与接收能力ok，服务端的接收和发送能力ok。
第三次握手	客户端已经认为TCP连接已经成功。此时客户端收到了服务端的发送的报文。回复ack = y+1，表明收到了客户端发送的序列号y之前的全部数据，同时希望下次客户端从y+1处开始发。发送seq = x+1，表明我是按照服务端的要求从x+1处开始发送数据的。		服务端收到客户端发送的报文。【服务端】可以知道：服务端的发送能力和客户端的接收能力ok。
最终状态	客户端进入Establish状态	服务端进入Establish状态

1、为什么需要三次握手，而不是两次？

原因	描述
原因一	三次握手才能让客户端与服务端双方都确认自己与对方的【发送与接收能力】没问题；
原因二	三次握手可以告知对方自己的初始序列号，并收到对方的初始序列号。以保证TCP连接的可靠性；如果只有两次握手，只有发送方的初始序列号能得到确认，而服务端的初始序号列得不到确认。
原因三	防止已过期的连接请求报文突然又传到服务器，导致服务端无法关闭，造成资源浪费。

---

2、TCP在握手阶段如何管理客户端的连接？

TCP在握手解决服务端维护了两个队列：半连接队列、全连接队列

队列
半连接队列	在客户端第一次握手时，服务端会将此连接放入半连接队列进行管理，并回复SYN+ACK；SYN洪泛攻击就是占满半连接队列，从而影响到正常的服务；
全连接队列	在第三次握手客户端回复ACK后，服务端会将此连接加入到全连接队列中进行管理；若全连接队列满了，则服务端会根据tcp_abort_on_overflow参数进行操作。若参数为1则丢弃该ACK，若参数为1，则发送RST包到客户端，直接放弃此次连接。

针对TCP三次握手的中半连接队列的SYN洪泛攻击

SYN洪泛攻击	描述
攻击原理	攻击者通过伪造大量不存在的IP地址充当客户端，向服务端发送【SYN】报文，服务端收到后将连接放入半连接队列，并发送【SYN + ACK】进入syn_rcvd状态，等待客户端的确认。由于客户端的IP地址是不存在的，导致服务端需要不断地重新发送【ACK】直到超时。由于这些伪造的【SYN】包长时间占用未连接队列，影响了正常的SYN连接。耗费CPU与内存资源，导致系统运行缓慢，造成网络堵塞。
如何检测	当在服务器上看到大量半连接状态时，特别是源IP地址是随机的，基本上可断定这是一次SYN攻击。
如何防范	① 通过防火墙、路由器等进行IP请求过滤与防护。比如限制IP连接次数，限制每个IP一分钟内新建立的最大连接数； ② 通过加固TCP / IP协议栈防范，如增加最大半连接数，缩短超时时间等。 ③ 使用SYN cookies技术，延迟分配连接资源： 当服务器收到第一次握手请求时，不马上分配连接资源。而是计算一个随机值，在第二次握手时传给客户端。当客户端返回第三次握手时，服务端验证随机值是否正确。若确认无误才会进入TCP连接状态，开始分配资源；

---

3、三次握手过程中数据包丢失怎么办？

丢失情况	客户端	服务端
第一次握手的SYN包丢失	客户端根据重传SYN数据包，重传次数超过阈值时放弃	服务端依然处于Lisener状态，没有收到SYN包
第二次握手的SYN包、ACK包丢失	客户端没有收到第一次握手的ACK包，触发超时重传	服务端发送SYN包后也没有收到ACK包，也会触发超时重传
第三次握手的ACK包丢失	客户端经过第二次握手，已经认为TCP连接已经建立。若第三次握手的ACK包丢失，则服务端不会开启成功。此时要根据客户端是否开启保活机制来分为以下两种情况： ① 若客户端开启了保活机制，则一段时间后双方都没发送数据后，客户端将发送一个心跳检测报文，服务端收到后应该回复ACK。但是服务端由于没有建立成功，已经关闭了。此时保活机制会发现服务端已关闭，就会回复RST包。客户端收到后，就知道三次握手失败。 ② 若客户端没有开启保活机制，则客户端由于已经认为TCP连接建立。因此会正常发送数据，此时若已知收不到服务端的ACK回应，会触发超时重传，重传次数超过阈值后就会放弃，客户端断开连接。	服务端由于收不到第二次握手时SYN包的ACK，则会触发超时重传。重传次数超过阈值后，仍然没有收到客户端的ACK应答，则一段时间后，服务端会自动关闭该连接。

4、TCP保活机制

保活机制	描述
概念	在需要长连接的网络通信程序中，经常需要心跳检测机制，来实现检测对方是否在线或者维持网络连接的需要。这一机制是在应用层实现的，对应的，在TCP协议中，也有类似的机制，就是TCP保活机制。
实现原理	保活机制是由一个 保活计时器 实现的。当计时器被激发，TCP建立连接一段时间后，开启保活机制的一端将发送保活探测报文，另一端收到后会发送一个ACK作为响应。
保活配置	【保活时间】 默认7200秒，两个小时内双方没有数据交互，就会触发保活机制。 【保活时间间隔】 触发保活机制后，默认每75秒发送一个探测报文； 【保活探测数】 默认9次；9次后依然没有收到另一端的ACK，就会认为对方连接已断开；
保活情况	【情况1】 请求端发送探测报文后，对方回复ACK，说明对方仍在在工作。此时请求端重置保活计时器(重新恢复7200秒)。 【情况2】 请求端已经发送了最大次数的探测报文，仍然没有收到对方的ACK。则请求端认为对方已经宕机，则主动断开连接。 【情况3】 对方主机已经宕机，此时若请求端发送探测报文，则对方回复RST报文。请求端收到RST响应后，就主动断开连接。 【情况4】 对方主机仍然在工作，但是由于网络原因，回复的ACK无法达到请求端。
保活弊端	【弊端1】 根据上述的四种保活情况分析可知：保活机制无法区分【情况2】与【情况4】。如果是由于网络原因，对方回复的ACK无法达到请求端，此时保活机制会断开一个好的连接。 【弊端】 保活机制会占用额外的带宽；

---

5、初始序列号为什么随机产生？

• 为了网络安全，防止黑客获取到初始化序列号，并伪造序列号进行攻击。

---

三、TCP四次挥手过程

阶段	客户端	服务端
初始状态	Established状态	Established状态
第一次挥手	客户端向服务端发送释放连接的请求报文 (FIN=1，ACK=1)，主动释放关闭连接，同时等待服务端的确认；
第二次挥手		服务端收到释放连接的报文后，立即回复确认报文 (ACK=1)，并进入CLSOE_WAIT状态
第三次挥手	客户端收到服务端的ACK后，主动释放与服务端的连接（客户端释放的是与服务端的连接，客户端与TCP的连接没有释放）。	此时服务端与客户端的连接还没有释放。服务端向客户端发送释放连接的请求报文 (FIN=1,ACK=1)，主动关闭连接，同时等待客户端的确认。
第四次挥手	客户端收到释放连接的报文后，立即回复确认报文 (ACK=1)，并进入TIME_WAIT状态；
最终状态	客户端经过2MSL的等待时间后，释放与TCP的连接，进入CLOSE状态 ；	服务端收到确认报文ACK后，立即释放与TCP的连接，服务端进入CLOSE状态；

---

1、为什么建立连接时是三次握手，关闭连接时却是四次挥手？

原因	服务端的ACK与FIN需要分开发送，从而导致多了一次，因此需要四次挥手。
Step1	由于客户端是主动发起关闭连接的，此时服务端可能还有未发送完毕的数据。因此服务端收到客户端的FIN报文后，不能立刻关闭连接，但是服务端还需要对客户端做出应答ACK；
Step2	当服务端向客户端的数据发送完毕后，此时服务端再向客户端主动发送FIN报文，表示数据已经发送完毕，请求关闭连接。

---

2、为什么客户端关闭连接需要进入TIME-WAIT状态等待2MSL？

关键	描述
原因一	⭐确保第四次挥手阶段的ACK确认报文能够达到服务端，从而使服务端正常关闭连接； 解释： 第四次挥手时，客户端的ACK由于网络阻塞等原因不一定能够顺利达到服务端。服务端接收不到则会进行超时重传FIN/ACK报文，此时如果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟接收不到FIN报文的ACK，就无法断开连接，造成资源浪费。 延伸： MSL是报文段在网络连接中存活的最长时间。客户端等待2MSL的时间 =【客户端ACK报文的1MSL超时】+【服务端FIN报文1MSL传输】，就能收到服务端重传的FIN/ACK报文，然后客户端重传一次ACK报文，并启动2MSL的计时器。如此就能保证服务端能够正常关闭。
原因二	⭐ 防止已失效的报文出现在之后的TCP连接中； 解释： TCP要求在2MSL的时间内不能使用相同的序列号。客户端进入TIME_WAIT状态等待2MSL时间，就能保证本次TCP连接内使用的报文全部失效。从而使得下从TCP连接中不会出现之前的报文。

---

3、如果已经建立了连接，客户端出现了故障怎么办？

解决	描述
超时重传	当超过指定时间后客户端仍然没有回复ACK报文，那么服务端会根据超时重传机制重发报文段。当重传到最大次数后，客户端仍然没有回复，此时服务端就断开连接。
保活机制	若服务端开启了保活机制，那么如果7200秒 (默认时间) 内双方都没有数据交互，此时服务端就会向客户端发送一个心跳探测报文。客户端收到后应该立即回复ACK。如果客户端没有回复，服务端会根据保活机制的默认设置每隔一段时间发送一次探测报文，若重发了最大次数后客户端仍然没有回复，则会认为客户端已经宕机，服务端会断开连接。

---

4、TIME_WAIT状态过多会产生什么问题？

TIME_WAIT	描述
TIME_WAIT 过多的危害	① 端口资源被过多占用： 一个TCP连接至少占用一个端口，端口一共就65536个，没有端口则就无法建立新的连接。 ② 服务器资源受限： 服务器监听一个端口，会把连接丢给线程处理，从而继续监听端口，但是线程池可能处理不了那么多连接。
TIME_WAIT 避免过多	① 服务端可以设置so_reuseaddr套接字选项来避免TIME_WAIT状态，此套接字告诉内核，此端口如果处于TIME_WAIT状态，可以继续重用该端口。 ② 修改内核参数 【tcp_tw_reuse = 1】表示允许TCP复用TIME_WAIT状态下的端口建立新的TCP连接。 【tcp_tw_recycle = 1】表示TCP快速对TIME_WAIT下的端口进行回收； ③ 服务端收到第四次挥手的ACK报文后，直接响应一个RST报文给客户端，从而快速结束客户端的TIME_WAIT状态； ④ 采用HTTP长连接，复用已建立的TCP连接，以避免过多的TIME_WAIT状态。

---

四、TCP协议如何保证可靠性

可靠性	描述
校验和	计算方式： 在数据 (报文) 传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。 发送方： 在发送数据之前计算检验和，并进行校验和的填充； 接收方： 收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。如果接收方计算的校验和与发送方的不一致，那么接收方就会丢弃； 包含信息： 源IP地址、目的地址、协议类型、TCP长度等；
序列号与确认应答	引入原因： 在TCP传输过程中，字节流传输是无序的，而且数据过大会进行拆包传输。此时就要考虑如何保证TCP传输过程中的有序性。而且TCP传输过程中有时由于网络抖动等原因无法保证数据包一定能传输成功，因此为了保证TCP传输的可靠性，引入确认应答机制。 序列号： TCP传输时，将每个字节的数据都进行了编号；有了序列号后，能够将接收到的数据根据序列号进行排序并去重，保证了数据传输的可靠性与有序性.解决了乱序的问题； 确认应答： TCP传输过程中，每次接收方收到数据后，都会都传输方进行确认应答ACK。ACK报文中包含了对应的序列号，告诉了对方我已收到了哪些数据，下次发送数据从哪里开始。解决了丢包的问题；
超时重传	发送端发出去的数据长时间没有收到确认应答ACK，则会触发超时重传机制。 (1) 若是由于网络抖动原因，对方已收到数据，但是回复ACK丢失。重传后接收方根据序列号判断数据已存在，则会直接丢弃，仍旧发送ACK确认应答； (2) 若接收方没有收到数据，此时重传后接收方收到数据会发送ACK确认应答； (3) 若超过最大重传次数后仍然没有收到接收方的确认应答，那么发送端就会断开连接。
滑动窗口	引入原因： 在进行数据传输时，若发送数据的长度大于缓冲区剩余的大小或者大于最大报文长度，就会进行拆包，而TCP传输过程中为了保证数据传输的可靠性与有序性，引入了序列号与确认应答机制。如此一来，发送端需要等待接收端回复ACK后才能继续发送数据，这样就会在等待确认应答的环节浪费时间。为了避免这种情况，TCP协议引入了滑动窗口，既提高了报文传输的效率，也避免了发送方发送过多的数据而导致接收方无法处理的问题。 滑动窗口中的数据是： 【已经发出但未收到ACK的数据】+【在窗口中还未发送出去的数据】 滑窗大小 = Math.min (拥塞窗口，流量窗口)： 窗口大小指的是，不需要等待确认应答ACK而可以继续发送数据包的最大值； 存在问题： TCP粘包、拆包问题、糊涂窗口等问题；
拥塞控制	引入原因： TCP传输的过程中，发送端开始发送数据时，如果初期网络拥堵，此时直接发送大量数据，会加剧网络拥堵问题，从而出现大量的丢包与超时重传的问题，严重影响TCP传输效率。 拥塞控制算法： 【慢启动】+【拥塞避免】+【快速重传】+【快速恢复】 ①【慢启动】 慢启动阶段的思路是，不要一开始就发送大量的数据，先发送少量数据探测网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小，在没有出现丢包时每收到一个 ACK 就将拥塞窗口大小加1（单位是 MSS，最大单个报文段长度），每轮次发送窗口增加一倍，呈指数增长。当拥塞窗口的大小达到慢启动阶段阈值时或者出现丢包现象，就进入拥塞避免算法。 ②【拥塞避免】 当拥塞窗口 >= 慢启动阀值时，就会进入拥塞避免阶段。此时拥塞窗口的大小不再是呈指数性增加，而是变为线性+1，慢慢的线性调整到网络的最佳值。当发生网络拥堵出现丢包问题时，触发快重传算法。 ③【快重传】 为了提高网络吞吐量，当接收端收到一个 失序 的报文段时可以立即发出要求重传的确认，而不必要等到自己传输数据的时候再捎带确认。快重传规定：发送方只要连续收到三个重传请求时就应该立即重传对方尚未收到的报文段，而不用等待重传计时器到期时再重传，大大的提高了重传效率。 ④【快恢复】 当发送方连续收到三个重传请求时，就执行 乘性减 算法，将慢启动阶段阈值变为当前拥塞窗口的一半，这是为了预防网咯发用拥塞。由于发送方已经能连续收到三个重传请求，会认为当前网络并不是特别拥堵。所以不执行慢启动算法，而是将拥塞窗口的值设置为慢开始阈值减半后的值，接着执行拥塞避免算法，线性+1，快速恢复。
流量控制	引入原因： 如果主机A一直向主机B发送数据，而不考虑主机B的接收能力，那么会导致主机B的接收缓冲区满了，无法再接收新的数据，从而导致大量的丢包，引发重传机制。但是如果重传过程中，主机B的接收能力依然没有好转，那么会将有大量的时间浪费在超时重传上，导致TCP传输效率降低。因此引入了流量控制，主机B告诉主机A自己接收缓冲区的大小，来使主机A控制发送的数据量。流量控制与TCP协议报头中的窗口大小有关。 实现原理： TCP为每个连接维护了一个持续计数器，只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若计时器到期，就发送一个零窗口探测报文段，接收方确认后回复当前的窗口值。若窗口依然为0，那么就重置持续计数器，直到窗口不为0，可继续传送数据；

---

五、TCP糊涂窗口问题

糊涂窗口	描述
问题 概述	糊涂窗口指的是，接收方通告了接收缓冲区缩小（滑动窗口变小），但是发送方即使窗口变小依然发送数据；
如何解决	【发送方】 使用Nagle算法，指的是当发送端若发送的数据很少，进行延迟发送的一种机制；具体来说，当要发送的数据大小 ≥ 内核缓冲区大小的一半时，才可以发送数据。 【接收方】 窗口设置为0或者延迟确认应答机制；  方案一： 只要窗口大小 < 内核缓冲区的一半时，就直接将窗口的大小设置为0，并通告发送端。待等到窗口大小 ＞ 内核缓冲区的一半时，再打开窗口，通告发送端可以发送数据。这样就防止发送小报文了；  方案二： 延迟确认应答机制。延迟确认应答基于以下思想，如果接收报文后立即回复ACK，此时滑窗可能依然很小，发送方收到ACK后还是会发送小报文。如果接收方延迟一段时间后再确认应答，此时滑窗大小可能就变大了，这样发送方就能发送多的数据了；

---

七、Http协议

1、Http常见的状态码

状态码	描述
200	服务器已经成功处理了请求；
301	请求的网页已经永久移动到了新位置，服务器会返回此响应，并自动将请求者转到新位置；原网址已经不在能提供请求服务；
302	请求的网页临时移动到了新位置，但是请求者依然可以继续使用原网址进行后续的请求；
400	客户端请求存在语法错误，不能被服务器所理解；
403	服务器收到请求，但是拒绝提供服务；
404	服务器找不到请求的网页；
500	服务器内部遇到错误，无法完成请求；

---

2、Http常用的请求方式

请求方式	作用
增：PUT	上传文件，向服务器添加数据，可以看作增
删：DELETE	删除文件
改：POST	安全的传输数据，向服务器提交数据，对服务器数据进行更新
查：GET	有风险的获取资源，查询服务器资源

---

3、GET请求和POST请求的区别

区别	GET	POST
提交方式	使用URL或Cookie传参	将数据放入Body中传参
长度限制	有限制	无限制
安全性	不安全，URL和Cookie在浏览器与地址栏上可见，容易被获取	Post数据更安全
幂等性	是	不是