计算机网络编程基础

膜拜各位大佬，整理他们的成郭如下

1.网络模型

TCP/IP(Transmission Control Protocol/Internet Protocol)是一系列协议的集合，是构成网络通信的核心骨架，它定义了电子设备如何连入因特网，以及数据如何在它们之间进行传输

各层作用：

推荐一个个人感觉还不错的图，基础都包括啦：计算机网络编程基础知识总结思维导图

这里写图片描述

接下来说明一下TCP与UDP

2.TCP

面向连接，提供可靠的服务，有流量控制，拥塞控制，无重复、无丢失、无差错，面向字节流(把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块)，只能是点对点，首部 20 字节，全双工

TCP报文首部格式:
在这里插入图片描述

解释：

源端口和目的端口: 各占两个字节，分别写入源端口号和目的端口号。
序号：占4个字节；用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。
确认号 ：占4个字节；期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。
数据偏移：占4位；指的是数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。
确认 ACK ：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
窗口：占2字节；窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。
检验和：占2个字节；检验和字段检验的范围包括首部和数据这两个部分。在计算检验和时，在TCP报文段的前面加上12字节的伪首部。
套接字： TCP连接的端点叫做套接字或插口。端口号拼接到IP地址即构成了套接字。

在上述字段中，6位标志域的各个选项功能如下。

URG：紧急标志。紧急标志为"1"表明该位有效。

ACK：确认标志。表明确认编号栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号（w+1）为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。

PSH：推标志。该标志置位时，接收端不将该数据进行队列处理，而是尽可能快地将数据转由应用处理。在处理Telnet或rlogin等交互模式的连接时，该标志总是置位的。

RST：复位标志。用于复位相应的TCP连接。

SYN：同步标志。表明同步序列编号栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端（一般是客户端）的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。

TCP的三次握手与四次挥手

具体过程如下：

第一次握手：建立连接。客户端发送连接请求报文段，并将syn(标记位)设置为1，Squence Number(数据包序号)(seq)为x,接下来等待服务端确认，客户端进入SYN_SENT状态(请求连接)；
第二次握手：服务端收到客户端的 SYN 报文段，对 SYN 报文段进行确认，设置 ack(确认号)为 x+1(即seq+1 ; 同时自己还要发送 SYN 请求信息，将 SYN 设置为1, seq为 y。服务端将上述所有信息放到 SYN+ACK 报文段中，一并发送给客户端，此时服务器进入 SYN_RECV状态。

SYN_RECV是指,服务端被动打开后,接收到了客户端的SYN并且发送了ACK时的状态。再进一步接收到客户端的ACK就进入ESTABLISHED状态。
第三次握手：客户端收到服务端的 SYN+ACK(确认符) 报文段；然后将 ACK 设置为 y+1,向服务端发送ACK报文段，这个报文段发送完毕后，客户端和服务端都进入ESTABLISHED(连接成功)状态，完成TCP 的三次握手。

上面的解释可能有点不好理解，用《图解HTTP》中的一副插图帮助大家。

当客户端和服务端通过三次握手建立了 TCP 连接以后,当数据传送完毕,断开连接就需要进行TCP的四次挥手。其四次挥手如下所示：

第一次挥手

客户端设置seq和 ACK ,向服务器发送一个 FIN(终结)报文段。此时，客户端进入 FIN_WAIT_1 状态，表示客户端没有数据要发送给服务端了。
第二次挥手

服务端收到了客户端发送的 FIN 报文段，向客户端回了一个 ACK 报文段。
第三次挥手

服务端向客户端发送FIN 报文段，请求关闭连接，同时服务端进入 LAST_ACK 状态。
第四次挥手

客户端收到服务端发送的 FIN 报文段后，向服务端发送 ACK 报文段,然后客户端进入 TIME_WAIT 状态。服务端收到客户端的 ACK 报文段以后，就关闭连接。此时，客户端等待 2MSL（指一个片段在网络中最大的存活时间）后依然没有收到回复，则说明服务端已经正常关闭，这样客户端就可以关闭连接了。

最后再看一下完整的过程：

如果有大量的连接，每次在连接，关闭都要经历三次握手，四次挥手，这显然会造成性能低下。因此。Http 有一种叫做长连接（keepalive connections）的机制。它可以在传输数据后仍保持连接，当客户端需要再次获取数据时，直接使用刚刚空闲下来的连接而无需再次握手。

一些问题汇总：

1. 为什么要三次握手？

为了防止已失效的连接请求报文突然又传送到了服务端，因为产生错误。

具体解释： “已失效的连接请求报文段”产生情况：

client 发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间滞留，因此导致延误到连接释放以后的某个时间才到达 service。如果没有三次握手，那么此时server收到此失效的连接请求报文段，就误认为是 client再次发出的一个新的连接请求，于是向 client 发出确认报文段，同意建立连接，而此时 client 并没有发出建立连接的情况，因此并不会理会服务端的响应，而service将会一直等待client发送数据，因此就会导致这条连接线路白白浪费。

如果此时变成两次挥手行不行？

这个时候需要明白全双工与半双工，再进行回答。比如：

第一次握手： A给B打电话说，你可以听到我说话吗？

第二次握手： B收到了A的信息，然后对A说：我可以听得到你说话啊，你能听得到我说话吗？

第三次握手： A收到了B的信息，然后说可以的，我要给你发信息啦！

在三次握手之后，A和B都能确定这么一件事：我说的话，你能听到；你说的话，我也能听到。 这样，就可以开始正常通信了，如果是两次，那将无法确定。

2. 为什么要四次挥手？

TCP 协议是一种面向连接，可靠，基于字节流的传输层通信协议。TCP 是全双工模式(同一时刻可以同时发送和接收)，这就意味着，当主机1发出 FIN 报文段时，只是表示主机1已结没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回 ACK报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会中断这次TCP连接。

3.为什么要等待 2MSL

MSL：报文段最大生存时间，它是任何报文段被丢弃前在网络内的最长时间

原因如下：

保证TCP协议的全双工连接能够可靠关闭

保证这次连接的重复数据从网络中消息

第一点：如果主机1直接关闭，由于IP协议的不可靠性或者其他网络原因，导致主机2没有收到主机1最后回复的 ACK。那么主机2就会在超时之后继续发送 FIN，此时由于主机1已经关闭，就找不到与重发的 FIN 对应的连接。所以，主机1 不是直接进入关闭，而是TIME_WAIT 状态。当再次收到 FIN 的时候，能够保证对方收到 ACK ，最后正确关闭连接。

第二点：如果主机1直接关闭，然后又再向主机 2 发起一个新连接，我们不能保证这个新连接与刚才关闭的连接端口是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但还是有特殊情况出现；假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中( Lost Duplicate )，那些延迟数据在建立新连接之后才到达主机2，由于新连接和老连接的端口号是一样的，TCP 协议就认为哪个延迟的数据时属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接要在 TIME_WAIT 状态等待两倍 MSL ，保证本次连接的所有数据都从网络中消失。