[计算机网络]——知识点总结

一定会去到彩虹海的麦当

已于 2022-02-18 10:15:54 修改

阅读量3.5k

点赞数 26

分类专栏：计算机基础文章标签：网络网络协议 http

于 2022-02-16 21:01:40 首次发布

本文链接：https://blog.csdn.net/weixin_65349299/article/details/122971819

版权

计算机基础专栏收录该内容

5 篇文章 1 订阅

订阅专栏

🏳️‍🌈个人网站：code宝藏 👈，欢迎访问🎉🎉
🙏如果大家觉得博主写的还不错的话，可以点点关注，及时获取我的最新文章
🤝非常感谢大家的支持与点赞👍
📚笔记整理自小林coding的《图解网络》，作者写的很不错，我自己整理一下方便后期复习

文章目录

计算机网络体系机构

七层模型与四层模型

TCP/IP 体系结构相当于将 OSI 体系结构的物理层和数据链路层合并为了网络接口层，并去掉了会话层和表示层。

TCP/IP 在网络层使用的协议是 IP 协议，IP 协议的意思是网际协议，因此TCP/IP 体系结构的网络层称为网际

五层模型

教学时把 TCP/IP 体系结构的网络接口层分成了物理层和数据链路层

各层作用

1、物理层

采用怎样的传输媒体（介质）
采用怎样的物理接口
使用怎样的信号表示比特0和1

2、数据链路层

如果这些0，1组合的传送毫无规则的话，计算机是解读不了的。我们需要制定一套规则来进行0，1的传送。例如多少个电信号为一组啊，每一组信号应该如何标识才能让计算机读懂啊等等。以太网协议规定，一组电信号构成一个数据包，我们把这个数据包称之为帧。每一个桢由标头(Head)和数据(Data)两部分组成。

如何标识网络中的各主机（主机编址问题，例如MAC地址）
如何让计算机读懂我们传送的比特流
如何协调各主机争用总线

3、网络层

我们如何区分哪些MAC地址是属于同一个子网的呢？假如是同一个子网，那我们就用广播的形式把数据传送给对方，如果不是同一个了网的，我们就会把数据发给网关，让网关进行转发。
为了解决这个问题，于是，有了IP协议。

如何标识各网络以及网络中的各主机（网络和主机共同编址的问题，例如IP地址），实现主机与主机之间的通信，也叫点对点（end to end）通信
路由器如何转发分组，如何进行路由选择

4、运输层

计算机里面有各种各样的应用程序，计算机该如何知道这些数据是给谁的呢?

在从计算机A传数据给计算表B的时候，还得指定一个端口，以供特定的应用程序来接受处理。

如何解决进程之间基于网络的通信问题
出现传输错误时，如何处理

5、应用层

应用层该用什么方法（应用层协议）去解析数据

有关于这个地方的内容，大家可以去读一下这篇文章：讲一下网络五层模型，每一层的职责？

各层设计的协议

Http相关面试题

Http基本知识

1、Http是什么？

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。

2、能否详细解释「超文本传输协议」？

协议：Http是一个用在计算机世界的协议，它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范，以及相关的各种控制和错误处理方式（行为约定和规范）

传输：HTTP 是一个在计算机世界里专门用来在两点之间传输数据的约定和规范

超文本：超越了普通文本的文本，它是文字、图片、视频等的混合体，最关键有超链接，能从一个超文本跳转到另外一个超文本

HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」

3、Http常见的状态码

分类

常见状态码：

101：切换请求协议，从HTTP 切换到WebSocket
200：请求成功，有响应体301永久重定向：会缓存
302：临时重定向：不会缓存
304：协商缓存命中
403：服务器禁止访问
404：资源未找到
400：请求错误
500：服务器端错误
503：服务器繁忙

4、Http常见字段

Host 字段：客户端发送请求时，用来指定服务器的域名。

Content-Length 字段：服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。

Connection 字段：常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。

HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive 。

Content-Type 字段：用于服务器回应时，告诉客户端，本次数据是什么格式。

客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。

Content-Encoding 字段：说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式

客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。

GET与POST

1、GET与POST的区别

使用场景
GET用于获取资源，而POST用于传输实体主体。
参数
GET和POST的请求都能使用额外的参数，但是GET的参数是以查询字符串出现在URL中，而POST 的参数存储在实体主体中。

2、GET和POST方法都是安全和幂等的吗

在HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
所谓的「幕等」，意思是多次执行相同的操作，结果都是「相同」的。

GET方法是安全且幂等的，POST是不安全和不幂等的

Http特性

1、HTTP（1.1）的优点有哪些，怎么体现的？

HTTP 最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。

简单

HTTP 基本的报文格式就是 header + body ，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛
灵活和易于扩展

Http协议里面的每个组成要求都没有被固定死，都允许开发人员自定义和扩充
应用广泛和跨平台

从台式机的浏览器到手机上的各种 APP，HTTP 的应用片地开花，同时天然具有跨平台的优越性

2、缺点

HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。

（1）无状态：

好处

不需要额外的资源来记录状态信息，这能减轻服务器的负担
坏处

进行一系列有关联操作时，而这些操作都要知道用户的身份，但服务器没有记忆能力，就无法判断这些请求是有关联的，每次都要问一遍身份信息

（2）明文传输

好处

在传输过程中的信息，是可方便阅读的，为我们调试工作带来了极大的便利性
坏处

在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取

（3）不安全

通信使用明文（不加密），内容可能会被窃听
不验证通信方的身份，因此有可能遭遇伪装
无法证明报文的完整性，所以有可能已遭篡改

HTTP与HTTPS

1、HTTP 与 HTTPS 有哪些区别？

HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
HTTP 的端口号是 80，HTTPS 的端口号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

2、HTTPS解决了HTTP的哪些问题

HTTP 由于是明文传输，存在这窃听、篡改、冒充这三个风险

而HTTPS解决了上述风险：

混合加密的方式实现信息的机密性，解决了窃听的风险。
摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
将服务器公钥放入到数字证书中，解决了冒充的风险。

混合加密

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

非对称加密可以安全地交换密钥，但速度慢，对称加密运算速度快，但无法做到安全的密钥交换

数字证书

客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

这就存在些问题，如何保证公钥不被篡改和信任度？

所以这里就需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

3、HTTPS是如何建立连接的？

SSL/TLS 协议基本流程：

客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是握手阶段

4、SSL/TLS 的「握手阶段」的四次通信

（1）ClientHello

首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

客户端支持的 SSL/TLS 协议版本
客户端生产的随机数（ Client Random ），后面用于生产「会话秘钥」。
客户端支持的密码套件列表，如 RSA 加密算法。

（2）SeverHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello 。服务器回应的内容有如下内容：

确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。
服务器生产的随机数（ Server Random ），后面用于生产「会话秘钥」。
确认的密码套件列表，如 RSA 加密算法。
服务器的数字证书

（3）客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

一个随机数（ pre-master key ）。该随机数会被服务器公钥加密。
加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

（4）服务器的最后回应

服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：

加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信
服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

HTTP/1.1、HTTP/2、HTTP/3 演变

1、 HTTP/1.1 相比 HTTP/1.0 提高了什么性能？

HTTP/1.1 相比 HTTP/1.0 性能上的改进：

使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。支
持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

但 HTTP/1.1 还是有性能瓶颈：

请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；发
送冗长的首部。每次互相发送相同的首部造成的浪费较多；
服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
没有请求优先级控制；请求只能从客户端开始，服务器只能被动响应。

2、针对 HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。那 HTTP/2 相比 HTTP/1.1 性能上的改进：

（1）头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。

这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

（2）二进制格式

HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧

（3）数据流

HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

每个请求或回应的所有数据包，称为一个数据流（ Stream ）。

每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数客户端还可以指定数据流的优先级。

优先级高的请求，服务器就先响应该请求。

（4）多路复用

HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应

移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。

（5）服务器推送

HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。

3、HTTP/2 有哪些缺陷？HTTP/3 做了哪些优化？

HTTP/2 多个请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。

这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP

IP相关知识

IP地址基本认识

IP 地址（IPv4 地址）由 32 位正整数来表示，IP 地址在计算机是以二进制的方式处理的。

IP地址分类

IP 地址分类成了 5 种类型，分别是 A 类、B 类、C 类、D 类、E 类

上图中黄色部分为分类号，用以区分 IP 地址类别。

IP分类的情况，同一网络下没有地址层次，且不能很好的与现实网络匹配

无分类地址CIDR

这种方式不再有分类地址的概念，32 比特的 IP 地址被划分为两部分，前面是网络号，后面是主机号。

如何划分

（1）表示形式 a.b.c.d/x ，其中 /x 表示前 x 位属于网络号， x 的范围是 0 ~ 32 ，这就使得 IP 地址更加具有灵活性。

比如 10.100.122.2/24，这种地址表示形式就是 CIDR，/24 表示前 24 位是网络号，剩余的 8 位是主机号

（2）子网掩码

将子网掩码和 IP 地址按位计算 AND，就可得到网络号。

IPV4 地址不够如何解决

1、NAT

其实我们平时上网，电脑的IP地址都是属于私有地址，无法出网关，我们的数据都是通过网关来中转的，这个其实NAT 协议，可以用来暂缓IPV4 地址不够

2、IPV6

IPv6：作为接替IPv4的下一代互联网协议，其可以实现2的128次方个地址，而这个数量级，即使是给地球上每一颗沙子都分配一个IP地址，该协议能够从根本上解决IPv4地址不够用的问题。

IP（网络层）和 MAC （数据链路层）之间的区别和关系

IP 的作用是主机之间通信用的，而 MAC 的作用则是实现「直连」的两个设备之间通信，而 IP 则负责在「没有直连」的两个网络之间进行通信传输

在网络中数据包传输中，源IP地址和目标IP地址在传输过程中是不会变化的，只有源 MAC 地址和目标 MAC 一直在变化

DNS

通常使用的方式是域名，而不是 IP 地址，因为域名方便人类记忆。

域名的层级关系类似一个树状结构：

根 DNS 服务器
顶级域 DNS 服务器（com）
权威 DNS 服务器（server.com）

域名解析的工作流程

浏览器首先看一下自己的缓存里有没有，如果没有就向操作系统的缓存要，还没有就检查本机域名解析文件 hosts ，如果还是没有，就会 DNS 服务器进行查询，查询的过程如下：

客户端首先会发出一个DNS请求，问www.server.com的IP是啥，并发给本地DNS服务器（也就是客户端的TCP/IP设置中填写的DNS服务器地址）
本地域名服务器收到客户端的请求后，如果缓存里的表格能找到www.server.com，则它直接返回IP地址。如果没有，本地DNS会去问它的根域名服务器：“老大，能告诉我www.server.com的IP地址吗？”根域名服务器是最高层次的，它不直接用于域名解析，但能指明一条道路。
根DNS 收到来自本地DNS 的请求后，发现后置是.com，说："www.server.com这个域名归com区域管理”，我给你.com顶级域名服务器地址给你，你去问问它吧。
本地DNS收到顶级域名服务器的地址后，发起请求问“老二，你能告诉我www.server.com的IP地址吗？
顶级域名服务器说：“我给你负责www.server.com区域的权威DNS服务器的地址，你去问它应该能问到”。
本地DNS于是转向问权威DNS服务器：“老三，www.server.com对应的IP是啥呀？”server.com的权威DNS服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主
权威DNS服务器查询后将对应的IP地址X.X.X.X告诉本地DNS。
本地DNS 再将IP 地址返回客户端，客户端和目标建立连接，

ARP

在传输一个 IP 数据报的时候，确定了源 IP 地址和目标 IP 地址后，就会通过主机「路由表」确定 IP 数据包下一跳。然而，网络层的下一层是数据链路层，所以我们还要知道「下一跳」的 MAC 地址。

由于主机的路由表中可以找到下一跳的 IP 地址，所以可以通过 ARP 协议，求得下一跳的 MAC 地址。

ARP 是借助 ARP 请求与 ARP 响应两种类型的包确定 MAC 地址的

主机会通过广播发送 ARP 请求，这个包中包含了想要知道的 MAC 地址的主机 IP 地址。
当同个链路中的所有设备收到 ARP 请求时，会去拆开 ARP 请求包里的内容，如果 ARP 请求包中的目标 IP 地址与自己的 IP 地址一致，那么这个设备就将自己的 MAC 地址塞入 ARP 响应包返回给主机

DHCP

电脑通常都是通过 DHCP 动态获取 IP 地址，大大省去了配 IP 信息繁琐的过程。

TCP相关知识

什么是TCP

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。

面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；
字节流：消息是「没有边界」的，所以无论我们消息有多大都可以进行传输。并且消息是「有序的」，当「前一个」消息没有收到的时候，即使它先收到了后面的字节，那么也不能扔给应用层去处理，同时对「重复」的报文会自动丢弃

如何唯一确定一个TCP连接

TCP 四元组可以唯一的确定一个连接，四元组包括如下：

源地址
源端口
目的地址
目的端口

源地址和目的地址的字段（32位）是在 IP 头部中，作用是通过 IP 协议发送报文给对方主机。

源端口和目的端口的字段（16位）是在 TCP 头部中，作用是告诉 TCP 协议应该把报文发给哪个进程。

有一个 IP 的服务器监听了一个端口，它的 TCP 的最大连接数是多少？

服务器通常固定在某个本地端口上监听，等待客户端的连接请求。因此，客户端 IP 和端口是可变的，其理论值计算公式如下:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ln6EF7aY-1645016355252)(C:/Users/wcl/AppData/Roaming/Typora/typora-user-images/image-20220216172605063.png)]

对 IPv4，客户端的 IP 数最多为 2 的 32 次方，客户端的端口数最多为 2 的 16 次方，也就是服务端单机最大 TCP 连接数，约为 2 的 48 次方。

当然，服务端最大并发 TCP 连接数远不能达到理论上限。

首先主要是文件描述符限制，Socket 都是文件，所以首先要通过 ulimit 配置文件描述符的数目；
另一个是内存限制，每个 TCP 连接都要占用一定内存，操作系统的内存是有限的。

UDP 和 TCP 有什么区别呢？分别的应用场景是？

区别

连接

TCP 是面向连接的传输层协议，传输数据前先要建立连接。

UDP 是不需要连接，即刻传输数据。
服务对象

TCP 是一对一的两点服务，即一条连接只有两个端点。

UDP 支持一对一、一对多、多对多的交互通信
可靠性

TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达。

UDP 是尽最大努力交付，不保证可靠交付数据。
拥塞控制、流量控制

TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。

UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。
首部开销

TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 20 个字节，如果使用了「选项」字段则会变长的。

UDP 首部只有 8 个字节，并且是固定不变的，开销较小。
传输方式

TCP 是流式传输，没有边界，但保证顺序和可靠。

UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

分片不同

TCP 的数据大小如果大于 MSS 大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装 TCP 数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。

UDP 的数据大小如果大于 MTU 大小，则会在 IP 层进行分片，目标主机收到后，在 IP 层组装完数据，接着再传给传输层，但是如果中途丢了一个分片，则就需要重传所有的数据包，这样传输效率非常差，所以通常 UDP 的报文应该小于 MTU。

应用场景

由于 TCP 是面向连接，能保证数据的可靠性交付，因此经常用于：

FTP 文件传输
HTTP / HTTPS

由于 UDP 面向无连接，它可以随时发送数据，再加上UDP本身的处理既简单又高效，因此经常用于：

包总量较少的通信，如 DNS 、 SNMP 等
视频、音频等多媒体通信
广播通信

三次握手

**刚开始客户端处于closed的状态，服务端处于listen状态。**然后

1、第一次握手：客户端给服务端发一个SYN报文，并指明客户端的初始化序列号ISN（c）。此时客户端处于SYN Send 状态。

2、第二次握手：服务器收到客户端的SYN报文之后，会以自己的SYN报文作为应答，并且也是指定了自己的初始化序列号 ISN（s），同时会把客户端的ISN +1作为ACK的值，表示自己已经收到了客户端的SYN，此时服务器处于SYN_RCVD的状态。

3、第三次握手：客户端收到SYN报文之后，会发送一个ACK报文，当然，也是一样把服务器的ISN+1作为ACK的值，表示已经收到了服务端的SYN 报文，此时客户端处于established状态。

4、服务器收到ACK报文之后，也处于established状态，此时，双方以建立起了链接

第三次握手是可以携带数据的，前两次握手是不可以携带数据的

第三次的话，此时客户端已经处于 established 状态，也就是说，对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以第三次是可以携带数据的。

如何在 Linux 系统中查看 TCP 状态？

TCP 的连接状态查看，在 Linux 可以通过 netstat -napt 命令查看

为什么是三次握手？不是两次、四次？

三次握手才可以阻止重复历史连接的初始化（主要原因）

如果是两次握手连接，就不能判断当前连接是否是历史连接，三次握手则可以在客户端（发送方）准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接
三次握手才可以同步双方的初始序列号

当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
三次握手才可以避免资源浪费

如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪
「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数

为什么客户端和服务端的初始序列号 ISN 是不相同的？

说明：如果要求客户端和服务端相同的话，则客户端的每次连接所产生的ISN也必须都是一样的

如果一个已经失效的连接被重用了，但是该旧连接的历史报文还残留在网络中，如果序列号相同，那么就无法分辨出该报文是不是历史报文，如果历史报文被新的连接接收了，则会产生数据错乱。

所以，每次建立连接前重新初始化一个序列号主要是为了通信双方能够根据序号将不属于本连接的报文段丢弃。

另一方面是为了安全性，防止黑客伪造的相同序列号的 TCP 报文被对方接收

四次挥手

刚开始双方都处于establised状态，假如是客户端先发起关闭请求，则：

1、第一次挥手：客户端发送一个FIN报文，报文中会指定一个序列号。此时客户端处于FIN WAIT1状态。

2、第二次挥手：服务端收到FIN之后，会发送ACK报文，且把客户端的序列号值+ 1作为ACK报文的序列号值，表明已经收到客户端的报文了，此时服务端处于CLOSE_WAIT状态。

3、第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给FIN报文，且指定一个序列号。此时服务端处于LAST ACK的状态。

4、第四次挥手：客户端收到FIN之后，一样发送一个ACK报文作为应答，且把服务端的序列号值+1作为自己ACK报文的序列号值，此时客户端处于TIME WAIT状态。需要过一阵子以确保服务端收到自己的ACK报文之后才会进入CLOSED状态

5、服务端收到ACK报文之后，就处于关闭连接了，处于CLOSED状态。

为什么挥手需要四次？

关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据
服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，从而比三次握手导致多了一次。

为什么 TIME_WAIT 等待的时间是 2MSL？

MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。

为什么需要 TIME_WAIT 状态？

主动发起关闭连接的一方，才会有 TIME-WAIT 状态。需要 TIME-WAIT 状态，主要是两个原因：

防止具有相同「四元组」的「旧」数据包被收到；

经过 2MSL 这个时间，足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。
保证「被动关闭连接」的一方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭；

TCP协议如何保证可靠传输

主要有校验和、序列号、超时重传、流量控制及拥塞控制等几种方法。

校验和

在发送算和接收端分别计算数据的校验和，如果两者不一致，则说明数据在传输过程中出现了差错，TCP将丢弃和不确认此报文段。

序列号：

TCP会对每一个发送的字节进行编号，接收方接到数据后，会对发送方发送确认应答(ACK报文)，并且这个ACK报文中带有相应的确认编号，告诉发送方，下一次发送的数据从编号多少开始发。如果发送方发送相同的数据，接收端也可以通过序列号判断出，直接将数据丢弃。

超时重传

就是在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据，也就是我们常说的超时重传

TCP 会在以下两种情况发生超时重传：

数据包丢失
确认应答丢失

快速重传

TCP 还有另外一种快速重传（Fast Retransmit）机制，它不以时间为驱动，而是以数据驱动重传。

快速重传的工作方式是当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。

滑动窗口

TCP利用滑动窗口实现流量控制的机制。滑动窗口（Sliding window）是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题。

TCP中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。

当滑动窗口为0时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个1字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大

流量控制

发送方不能无脑的发数据给接收方，要考虑接收方处理能力。如果一直无脑的发数据给对方，但对方处理不过来，那么就会导致触发重发机制，从而导致网络流量的无端的浪费。

为了解决这种现象发生，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为0，则发送方不能发送数据。

TCP 拥塞控制

如果网络出现拥塞，则会产生丢包等问题，这时发送方会将丢失的数据包继续重传，网络拥塞会更加严重，所以在网络出现拥塞时应注意控制发送方的发送数据，降低整个网络的拥塞程度。

为了进行拥塞控制，TCP发送方要维持一个拥塞窗口（cwnd）的状态变量。它和流量控制的滑动窗口是不一样的，滑动窗口是根据接收方数据缓冲区大小确定的，而拥塞窗口是根据网络的拥塞情况动态确定的，一般来说发送方真实的发送窗口为滑动窗口和拥塞窗口中的最小值。

慢开始

为了避免一开始发送大量的数据而产生网络阻塞，会先初始化cwnd为1，当收到ACK后到下一个传输轮次，cwnd为2，以此类推成指数形式增长。
拥塞避免

因为cwnd的数量在慢开始是指数增长的，为了防止cwnd数量过大而导致网络阻塞，会设置一个慢开始的门限值ssthresh，当cwnd>=ssthresh时，进入到拥塞避免阶段，cwnd每个传输轮次加1。
拥塞发生
- 超时重传
  - ssthresh 设为 cwnd/2
  - cwnd 重置为 1
  - 接着，就重新开始慢启动
- 快速重传
当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传
- cwnd = cwnd/2 ，也就是设置为原来的一半;
- ssthresh = cwnd ;
- 进入快速恢复算法
  
  （1）拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；
  
  （2）重传丢失的数据包；

键入网址后，期间发生了什么

解析URL，从而生成发送给 Web 服务器的请求信息
生产 HTTP 请求信息

对 URL 进行解析之后，浏览器确定了 Web 服务器和文件名，接下来就是根据这些信息来生成 HTTP 请求消息了。
DNS解析：浏览器查询DNS，获取域名对应的IP地址

具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。

对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析（此解析具有权威性）；

如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。

如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者选代查询；
TCP 连接：浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；在双方建立了连接后，给数据加上TCP头部，TCP 报文中的数据部分就是存放 HTTP 头部 + 数据，组装好 TCP 报文之后，就需交给下面的网络层处理。
远程定位IP

在 IP 协议里面需要有源地址 IP 和目标地址 IP。根据路由表规则，来判断哪一个网卡作为源地址 IP。这个判断相当于在多块网卡中判断应该使用哪个一块网卡来发送包。目标地址，我们已经通过DNS域名解析得到的Web服务器IP

到此，生产IP报文
两点传输——MAC

在网络中数据包传输中，源IP地址和目标IP地址在传输过程中是不会变化的，通过源 MAC 地址和目标 MAC 不断的变化来不断前进到达目标IP地址。

在 MAC 包头里需要发送方 MAC 地址和接收方目标 MAC 地址，用于两点之间的传输。

发送方的 MAC 地址获取就比较简单了，MAC 地址是在网卡生产时写入到 ROM 里的，只要将这个值读取出来写入到 MAC 头部就可以了。

接收方的MAC地址就需要ARP来获取

这里我们的第一个接收方是路由器，所以获取的是路由器的MAC地址

至此，我们便可以生产MAC报文
出口 —— 网卡
IP 生成的网络包只是存放在内存中的一串二进制数字信息，没有办法直接发送给对方。因此，我们需要将数字信息转换为电信号，才能在网线上传输，也就是说，这才是真正的数据发送过程。负责执行这一操作的是网卡
送别者 —— 交换机

交换机根据 MAC 地址表查找 MAC 地址，然后将信号发送到相应的端口。
出境大门 —— 路由器
我们需要根据路由表的网关列判断对方的地址。
- 如果网关是一个 IP 地址，则这个IP 地址就是我们要转发到的目标地址，还未抵达终点，还需继续需要路由器转发。
- 如果网关为空，则 IP 头部中的接收方 IP 地址就是要转发到的目标地址，也是就终于找到 IP 包头里的目标地址了，说明已抵达终点。
服务器处理请求并返回HTTP报文：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
浏览器解析渲染页面：浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据宣染页面，最终向用户呈现一个完整的页面。
连接结束。