计算机网络待更新

网络协议分层（四层五层都要会，大概能说出来干啥的）

应用层：

应⽤层通过应用进程间的交互来完成特定网络应用，不⽤去关⼼数据是如何传输的，应用层是⼯作在操作系统中的⽤户态，传输层及以下则⼯作在内核态。HTTP协议，DNS域名系统(Domain Name System）将域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网。

协议：支持邮件的SMTP，FTP

数据：应用层交互的数据单元称为报文。

传输层：为应用层提供数据支持，负责向两台主机进程之间的通信提供通用的数据传输服务

只有主机才有的层次

传输层定义了传输数据的协议和端口号，主要用用于数据的分段、传输和重组。

传输协议：TCP（支付宝）,UDP（抖音）。

传输控制协议 TCP（Transmission Control Protocol）–提供面向连接的，可靠的数据传输服务。
用户数据协议 UDP（User Datagram Protocol）–提供无连接的，尽最大努力的数据传输服务，实时性好，传输效率高，（不保证数据传输的可靠性）。

数据单元：数据段

网络层：提供的是主机之间的通信

不希望传输层协议处理太多的事情，只需要服务好应⽤即可，让其作为应⽤间数据传输的媒介，帮助实现应⽤到应⽤的通信，⽽实际的传输功能就交给下⼀层，也就是⽹络层（Internet Layer）。

网络层的任务就是选择合适的网间路由和交换结点，确保数据及时传送，实现主机与主机之间的通信。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。

主要是对数据包中的IP地址进行解析和封装，这一层数据叫做数据包，工作设备是：路由器、交换机，防火墙

网络层最常使用的是 IP 协议（Internet Protocol），IP 协议会将传输层的报文作为数据部分，再加上 IP 包头组装成 IP 报文，如果 IP 报文大小超过MTU（以太网中一般为 1500 字节）就会再次进行分片，得到一个即将发送到网络的 IP 报文。

一个是网络号，负责标识该 IP 地址是属于哪个子网的；
一个是主机号，负责标识同一子网下的不同主机；

除了寻址能力， IP 协议还有另一个重要的能力就是路由。实际场景中，两台设备并不是用一条网线连接起来的，而是通过很多网关、路由器、交换机等众多网络设备连接起来的，那么就会形成很多条网络的路径，因此当数据包到达一个网络节点，就需要通过算法决定下一步走哪条路径。

所以，IP 协议的寻址作用是告诉我们去往下一个目的地该朝哪个方向走，路由则是根据「下一个目的地」选择路径。寻址更像在导航，路由更像在操作方向盘。

数据链路层：负责通过一条链路从一个结点向另一个物理链路直接相连的相邻接点传送数据报

主要是对数据包中的MAC地址进行解析和封装，这一层数据叫做帧。工作设备是：网卡、网桥、交换机

MAC 的作⽤则是实现「直连」的两个设备之间通信，⽽ IP 则负责在「没有直连」的两个网络之间进⾏通信传输。

源IP地址和目标IP地址在传输过程中是不会变化的，只有源 MAC 地址和目标MAC ⼀直在变化。

每⼀台设备的网卡都会有⼀个 MAC 地址，它就是⽤来唯⼀标识设备的。路由器计算出了下⼀个目的地 IP 地址，再通过 ARP 协议找到该目的地的 MAC 地址，这样就知道这个 IP 地址是哪个设备的了。

物理层：

在物理层上所传送的数据单位是比特。

物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异， 使其上面的数据链路层不必考虑网络的具体传输介质是什么。

HTTP常见概念

HTTP报文结构

1.请求行

2.请求头

3.空行

4.消息主体
HTTP报文结构

HTTP 基本概念

HTTP 是⼀个在计算机世界⾥专⻔在「两点」之间「传输」⽂字、图⽚、⾳频、视频等「超⽂本」数据的「约定和规范」。

常见的状态码（实在记不住先记着五大类的）

1xx：表示接收的请求正在处理

2xx （3种）：表示服务器成功处理了客户端请求

200 OK：表示接收请求正常处理完毕并且返回，且响应头会有body数据；

204 No Content：表示客户端发送给客户端的请求得到了成功处理，但在响应头没有body数据；

206 Patial Content：表示响应返回的 body 数据并不是资源的全部。

3xx （5种）：客户端请求的资源发生了变动，需要客户端用新的URL重新发送请求获取资源，也就是重定向

301 Moved Permanently：永久性重定向，表示请求的资源已经不存在，需要改用新的URL再次访问；

302 Found：临时性重定向，表示请求的资源被还在，但是需要使用新的URL来访问；

301与302的区别：前者是永久移动，后者是临时移动（之后可能还会更改URL），301和302都会在响应头里面使用字段location，指明后续需要跳转的URL，浏览器会自动重定向新的URL

4xx （4种）：表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

401Unauthorized 未授权需要用户提供账户和密码

403 Forbidden：表示服务器禁⽌访问资源，并不是客户端的请求出错；跨域，或者路径写错

404 Not Found：表示服务器上无法找到请求的资源；

5xx （2种）：表示客户端请求报文正确，但是服务器内部发生了错误，属于服务器端的错误码

501 Not Implemented」表示客户端请求的功能还不⽀持，类似“即将开业，敬请期待”的意思。
502bad gateway

503 Server Unavailable：表示服务器当前很忙，暂时⽆法响应服务器，

Get 与 Post

Get ⽅法的含义是请求从服务器获取资源，这个资源可以是静态的⽂本、⻚⾯、图⽚视频等。（比如看文章）

POST它向 URI(Universal Resource Identifier, 通用的资源标志符) 指定的资源提交数据，数据就放在报⽂的 body ⾥。（比如留言）

是否为安全和幂等：先说明下安全和幂等的概念：
在 HTTP 协议⾥，所谓的「安全」是指请求⽅法不会「破坏」服务器上的资源。

所谓的「幂等」，意思是多次执⾏相同的操作，结果都是「相同」的。
那么很明显 GET ⽅法就是安全且幂等的，因为它是「只读」操作，⽆论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。
POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的

HTTP 特性

优点：简单，灵活和容易拓展，应用广泛和跨平台

缺点：无状态（同一个客户第二次访问跟第一次访问没区别），明文传输，不安全（通信使用明文，内容可能被窃听；不验证通信方的身份，因此可能遭遇伪装；无法验证报文完整性，有可能已经遭篡改）；

解决方案：用HTTPS的方式解决，引入SSL/TLS层

HTTPS 与 HTTP

TSL是运行在传输层之上的协议。

区别：

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

HTTPS 解决了 HTTP 的哪些问题？

HTTP 由于是明⽂传输，所以安全上存在以下三个⻛险：
窃听⻛险，⽐如通信链路上可以获取通信内容，⽤户号容易没。
篡改⻛险，⽐如强制植⼊垃圾⼴告，视觉污染，⽤户眼容易瞎。
冒充⻛险，⽐如冒充淘宝⽹站，⽤户钱容易没

HTTPS 在 HTTP 与 TCP 层之间加⼊了 SSL/TLS 协议，可以很好的解决了上述的⻛险：
信息加密：交互信息⽆法被窃取，但你的号会因为「⾃身忘记」账号⽽没。
校验机制：⽆法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾⼴告。
身份证书：证明淘宝是真的淘宝⽹，但你的钱还是会因为「剁⼿」⽽没

HTTPS 是如何解决上⾯的三个⻛险的

混合加密的⽅式实现信息的机密性，解决了窃听的⻛险。

摘要算法的⽅式来实现完整性，它能够为数据⽣成独⼀⽆⼆的「指纹」，指纹⽤于校验数据的完整性，解决了篡改的⻛险。

将服务器公钥放⼊到数字证书中，解决了冒充的⻛险。

混合加密：用来信息加密

HTTPS 采⽤的是对称加密和⾮对称加密结合的「混合加密」⽅式：
在通信建⽴前采⽤⾮对称加密的⽅式交换「会话秘钥」，后续就不再使⽤⾮对称加密。
在通信过程中全部使⽤对称加密的「会话秘钥」的⽅式加密明⽂数据。
采⽤「混合加密」的⽅式的原因：
对称加密只使⽤⼀个密钥，运算速度快，密钥必须保密，⽆法做到安全的密钥交换。
⾮对称加密使⽤两个密钥：公钥和私钥，公钥可以任意分发⽽私钥保密，解决了密钥交换问题但速度慢。

摘要算法：校验数据完整性，解决篡改风险

摘要算法⽤来实现完整性，能够为数据⽣成独⼀⽆⼆的「指纹」，⽤于校验数据的完整性，解决了篡改的⻛险。

客户端在发送明⽂之前会通过摘要算法算出明⽂的「指纹」，发送的时候把「指纹 + 明⽂」⼀同加密成密⽂后，发送给服务器，服务器解密后，⽤相同的摘要算法算出发送过来的明⽂，通过⽐较客户端携带的「指纹」和当前算出的「指纹」做⽐较，若「指纹」相同，说明数据是完整的

数字证书

客户端先向服务器端索要公钥，然后⽤公钥加密信息，服务器收到密⽂后，⽤⾃⼰的私钥解密。
这就存在些问题，如何保证公钥不被篡改和信任度？
所以这⾥就需要借助第三⽅权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的

关于非对称加密，数字证书，公钥和私钥、RSA

秘钥分类：

对称密钥加密（没有私钥公钥的概念），又称私钥加密或会话密钥加密算法，即信息的发送方和接收方使用同一个密钥去加密和解密数据。它的最大优势是加/解密速度快，适合于对大数据量进行加密，但密钥管理困难。私人的，不会公开。

非对称密钥加密系统（一个公开，一个是私人的，因为是公开的也称为公钥系统），又称公钥密钥加密。它需要使用不同的密钥来分别完成加密和解密操作，一个公开发布，即公开密钥，另一个由用户自己秘密保存，即私用密钥。信息发送者用公开密钥去加密，而信息接收者则用私用密钥去解密。公钥机制灵活，但加密和解密速度却比对称密钥加密慢得多。

非对称加密才可以实现机密性和认证性。
v从

非对称加密

数字证书原理、能否自己发布、怎么验证？

公钥和私钥

RSA

对称加密算法和非对称加密算法

对称加密算法：DES、AES
非对称加密：RSA,DSA

HTTP/1.1、 HTTP/2、 HTTP/3 演变（3不看）

说说 HTTP/1.1 相⽐ HTTP/1.0 提⾼了什么性能？

HTTP/1.0 默认使用的是短连接，每次请求都要重新建立一次连接。且HTTP是基于TCP/IP协议的，每次建立或者断开连接都要三次握手四次挥手的开销，这样开销比较大。

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

使⽤ TCP ⻓连接的⽅式改善了 HTTP/1.0 短连接造成的性能开销。能维持一个长连接，可以用多个长链接的方式发送多个请求，
⽀持管道（pipeline）网络传输，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去，可以减少整体的响应时间。（但是服务器还是按照顺序，先回应A请求，再回应B请求，前面的回应如果很慢，后面的很多请求排队等着，这就是队头阻塞）。

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

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

HTTP/2 相⽐ HTTP/1.1 性能上的改进：

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

1.头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是⼀样的或是相似的，那么，协议会帮你消除重复的部分。这就是所谓的 HPACK 算法：在客户端和服务器同时维护⼀张头信息表，所有字段都会存⼊这个表，⽣成⼀个索引号，以后就不发送同样字段了，只发送索引号，这样就提⾼速度了。

2.二进制格式
HTTP/2 不再像 HTTP/1.1 ⾥的纯⽂本形式的报⽂，⽽是全⾯采⽤了⼆进制格式，增加了数据传输的效率

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

数据流有独一无二的编号，用来标记，指出自己是属于哪一个回应。客户端还可以指定数据流的优先级，这样服务器就可以优先响应该请求。

4.多路复用

在⼀个连接中并发多个请求或回应，⽽不⽤按照顺序⼀⼀对应，也就不会再出现「队头阻塞」问题，降低了延迟，⼤幅度提⾼了连接的利⽤率。

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

HTTP/2 主要的问题在于，多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的重传机制，这样在⼀个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/1.1 中的管道（ pipeline）传输中如果有⼀个请求阻塞了，那么队列后请求也统统被阻塞住了
HTTP/2 多个请求复⽤⼀个TCP连接，⼀旦发⽣丢包，就会阻塞住所有的 HTTP 请求。

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

UDP 发⽣是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞和 HTTP/2 的⼀个丢包全部重传问题。
⼤家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC （Quick UDP Internet Connections）协议可以实现类似 TCP 的可靠性传输。

HTTP/1.1优化思路

第⼀个思路是，通过缓存技术来避免发送 HTTP 请求。客户端收到第⼀个请求的响应后，可以将其缓存在本地磁盘，下次请求的时候，如果缓存没过期，就直接读取本地缓存的响应数据。如果缓存过期，客户端发送请求的时候带上响应数据的摘要，服务器⽐对后发现资源没有变化，就发出不带包体的 304 响应，告诉客户端缓存的响应仍然有效。
第⼆个思路是，减少 HTTP 请求的次数，有以下的⽅法：

将原本由客户端处理的重定向请求，交给代理服务器处理，这样可以减少重定向请求的次数；
将多个⼩资源合并成⼀个⼤资源再传输，能够减少 HTTP 请求次数以及头部的重复传输，再来减少 TCP 连接数量，进⽽省去 TCP 握⼿和慢启动的⽹络消耗；
按需访问资源，只访问当前⽤户看得到/⽤得到的资源，当客户往下滑动，再访问接下来的资源，以此达到延迟请求，也就减少了同⼀时间的 HTTP 请求次数。

第三思路是，通过压缩响应资源，降低传输资源的⼤⼩，从⽽提⾼传输效率，所以应当选择更优秀的压缩算法。

TCP 和 UDP 区别

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

1.连接
TCP 是⾯向连接的传输层协议，传输数据前先要建⽴连接。
UDP 是不需要连接，即刻传输数据。

2.服务对象
TCP 是⼀对⼀的两点服务，即⼀条连接只有两个端点。
UDP ⽀持⼀对⼀、⼀对多、多对多的交互通信

3.可靠性
TCP 是可靠交付数据的，数据可以⽆差错、不丢失、不重复、按需到达。
UDP 是尽最⼤努⼒交付，不保证可靠交付数据。

4.拥塞控制、流量控制
TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。
UDP 则没有，即使⽹络⾮常拥堵了，也不会影响 UDP 的发送速率。

5.⾸部开销
TCP ⾸部长度较长，会有⼀定的开销，⾸部在没有使⽤「选项」字段时是 20 个字节，如果使⽤了「选项」字段则会变⻓的。
UDP ⾸部只有 8 个字节，并且是固定不变的，开销较⼩。

6.传输⽅式
TCP 是流式传输，但保证顺序和可靠。
UDP 是⼀个包⼀个包的发送，是有边界的，但可能会丢包和乱序。
TCP 和 UDP 应⽤场景：
由于 TCP 是⾯向连接，能保证数据的可靠性交付，因此经常⽤于：
FTP ⽂件传输（File Transfer Protocol，FTP）
HTTP / HTTPS
由于 UDP ⾯向⽆连接，它可以随时发送数据，再加上UDP本身的处理既简单⼜⾼效，因此经常⽤于：
包总量较少的通信，如 DNS 、 SNMP 等、视频、⾳频等多媒体通信、⼴播通信

TCP流式和UDP包

按层次分， TCP 位于传输层，提供可靠的字节流服务。所谓的字节流服务（Byte Stream Service）是指，为了方便传输，将大块数据分割成以报文段（segment）为单位的数据包进行管理。

为什么说UDP是面向报文的，而TCP是面向字节流的？

UDP是面向报文的：发送方的UDP对应用程序交下来的报文，在添加了首部之后就向下交付，UDP对应用层交付下来的报文即不合并也不拆分，而是保留这些报文的边界，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文，接收方UDP对下方交上来的UDP用户数据报，在去除首部之后就原封不动的交付给上层的应用程序，一次交付一个完整报文，所以是UDP是面向报文的

TCP是面向字节的：发送方TCP对应用程序交下来的报文数据块，视为无结构的字节流（无边界约束，可拆分/合并），但维持各字节流顺序（相对顺序没有变），TCP发送方有一个发送缓冲区，当应用程序传输的数据块太长，TCP就可以把它划分端一些再传输，如果应用程序一次只传输一个字节，那么TCP可以等待积累足够多的字节后再构成报文端发送出去，所以TCP的面向字节的

TCP报文段

6个控制位，一个占一位。

序列号 seq： 在建⽴连接时由计算机⽣成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送⼀次数据，就「累加」⼀次该「数据字节数」的⼤⼩。⽤来解决⽹络包乱序问题。
确认应答号 ack： 指下⼀次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。⽤来解决不丢包的问题。

HTTPS通信(先不看)

概念

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用
SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代
替而已。
HTTPS通信会先进行TCP三次握手，再进行TLS三次握手，之后再进行通信内容。

主要干了什么

商定双方通信所使用的的 TLS 版本 (例如 TLS1.0, 1.2, 1.3等等)；
确定双方所要使用的密码组合；
客户端通过服务器的公钥和数字证书 (上篇文章已有介绍)上的数字签名验证服务端的身份；
生成会话密钥，该密钥将用于握手结束后的对称加密。

TLS详细过程(先不看)

下面来看 TLS 握手的详细过程 (注：此图与HTTPS详解一中的 HTTPS 原理图的流程大致相同，不同的是此图把重点放在了TLS握手的相关概念上)：

根据小林的东西整理得到以下过程：
1、第一次握手：客户端⾸先会发⼀个「Client Hello」消息，以及⽣成的随机数（Client Random），这个随机数会被服务端保留，它是⽣成对称加密密钥的材料之⼀。
2、TLS 第⼆次握⼿
服务端收到信息后，返回信息，也会给出一个随机数（Server Random），密码套件里面会有密钥交换算法 +签名算法 + 对称加密算法 + 摘要算法

通过上面两次握手，客户端和服务端就已确认了 TLS 版本和使⽤的密码套件
服务端为了证明⾃⼰的身份，会发送「Server Certificate」给客户端，这个消息⾥含有数字证书。
3、三次握手
客户端验证完证书后，认为可信则继续往下⾛。接着，客户端就会⽣成⼀个新的随机数 (pre-master)，⽤服务器的 RSA 公钥加密该随机数，然后把消息传递给服务端。
此时客户端和服务端双⽅都共享了三个随机数，分别是 Client Random、 Server Random、 pre-master。

于是，双⽅根据已经得到的三个随机数，⽣成会话密钥（Master Secret），它是对称密钥，⽤于对后续的 HTTP请求/响应的数据加解密。

客户端发送一个用生成的绘话秘钥加密的消息，发送给服务端，让服务端做个验证

4、四次握手
也是同样操作，如果双方的验证加密解密都没有什么问题，握手就正式完成。

TCP三次握手，和四次挥手

只有在请求连接和请求连接的接受才会有SYN=1, 其他都是0

四次挥手中，

从上⾯的过程可以发现第三次握⼿是可以携带数据的，前两次握⼿是不可以携带数据的，这也是⾯试常问的题

⼀旦完成三次握⼿，双⽅都处于 ESTABLISHED 状态，此时连接就已建⽴完成，客户端和服务端就可以相互发送数据了。

你可以看到，每个⽅向都需要⼀个 FIN 和⼀个 ACK，因此通常被称为四次挥⼿

这⾥⼀点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态

为什么要三次握手

TCP头部格式含义：

序列号：用来解决网络包乱序问题。

确认应答号：用来解决不丢包的问题。

控制位：
ACK：该位为 1 时，「确认应答」的字段变为有效， TCP 规定除了最初建⽴连接时的 SYN 包之外该位必须设置为 1 。
RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
SYN：该位为 1 时，表示希望建⽴连接，并在其「序列号」的字段进⾏序列号初始值的设定。
FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双⽅的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

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

客户端连续发送多次 SYN 建⽴连接的报⽂，在网络拥堵情况下：⼀个「旧 SYN 报⽂」⽐「最新的 SYN 」报⽂早到达了服务端；那么此时服务端就会回⼀个 SYN + ACK 报⽂给客户端；客户端收到后可以根据⾃身的上下⽂，判断这是⼀个历史连接（序列号过期或超时），那么客户端就会发送RST 报⽂给服务端，表示中⽌这⼀次连接。

如果是两次握⼿连接，就不能判断当前连接是否是历史连接，三次握⼿则可以在客户端（发送⽅）准备发送第三次报⽂时，客户端因有⾜够的上下⽂来判断当前连接是否是历史连接：如果是历史连接（序列号过期或超时），则第三次握⼿发送的报⽂是 RST 报⽂，以此中⽌历史连接；如果不是历史连接，第三次发送的报文就是ACK报文，通信双方就会成功建立连接。

2.三次握⼿才可以同步双⽅的初始序列号

TCP 协议的通信双⽅，都必须维护⼀个「序列号」，序列号是可靠传输的⼀个关键因素，它的作⽤：

接收⽅可以去除重复的数据；
接收⽅可以根据数据包的序列号按序接收；
可以标识发送出去的数据包中，哪些是已经被对⽅收到的；

可⻅，序列号在 TCP 连接中占据着⾮常重要的作⽤，所以当客户端发送携带「初始序列号」的 SYN 报⽂的时候，需要服务端回⼀个 ACK 应答报⽂，表示客户端的 SYN 报⽂已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样⼀来⼀回，才能确保双⽅的初始序列号能被可靠的同步。

两次握⼿只保证了⼀⽅的初始序列号能被对⽅成功接收，没办法保证双⽅的初始序列号都能被确认接收。

3.三次握⼿才可以避免资源浪费

假如两次就可以建立连接，当客户端的SYN请求连接在网络中阻塞时，由于阻塞，服务器也不会去发ACK报文，超时后，客户端又会继续发送SYN请求连接，服务器不清楚客户端是否收到了⾃⼰发送的建⽴连接的 ACK 确认信号，所以每收到一个SYN就会主动建立一个连接。这样就会建立多个冗余无效连接，造成很大的资源浪费。

总结：

TCP 建⽴连接时，通过三次握⼿能防⽌历史连接的建⽴，能减少双⽅不必要的资源开销，能帮助双⽅同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。
不使⽤「两次握⼿」和「四次握⼿」的原因：
「两次握⼿」：⽆法防⽌历史连接的建⽴，会造成双⽅资源的浪费，也⽆法可靠的同步双⽅序列号；
「四次握⼿」：三次握⼿就已经理论上最少可靠连接建⽴，所以不需要使⽤更多的通信次数。

为什么挥⼿需要四次

再来回顾下四次挥⼿双⽅发 FIN 包的过程，就能理解为什么需要四次了。
关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
服务器收到客户端的 FIN 报⽂时，先回⼀个 ACK 应答报⽂，⽽服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报⽂给客户端来表示同意现在关闭连接。

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

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

MSL 是 Maximum Segment Lifetime，报⽂最⼤⽣存时间；

客户端给服务端发的ACK报文段后，如果没有到达，此时服务器会重新传送第三次的FIN+ACK报文段，A就会在2MSL时间内收到服务端重传的报文段，A会重传一次确认，然后计时器重启；如果没有等待这个时间，服务端一直收不到最后一次ACK，他就会一直发送第三次的报文段，这样服务端就无法关闭。
记住：此时客户端的状态时TIME-WAIT，服务端的状态是 LAST-ACK。

为什么需要 TIME_WAIT 状态？’

TCP连接的优化，根据图解网络中的TCP内核参数写的(先不看)

三次握手性能提升

四次挥手性能提升

TCP传输数据的性能提升

TCP 协议如何保证可靠传输

应用数据被分割成 TCP 认为最适合发送的数据块。
TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
校验和： TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。
TCP 的接收端会丢弃重复的数据。
流量控制： TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量控制）
拥塞控制：当网络拥塞时，减少数据的发送。
ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
超时重传：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

ARQ协议

自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。

停止等待ARQ协议自动重传请求（Automatic Repeat-reQuest，ARQ）

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组；
在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认；
优点：简单

缺点：信道利用率低，等待时间长

无差错情况:

发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。

出现差错情况（超时重传）:

停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。连续 ARQ 协议可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。

确认丢失和确认迟到

确认丢失：确认消息在传输过程丢失。当A发送M1消息，B收到后，B向A发送了一个M1确认消息，但却在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：1. 丢弃这个重复的M1消息，不向上层交付。 2. 向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失）。
确认迟到：确认消息在传输过程中迟到。A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会，A收到了B第一次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：1. A收到重复的确认后，直接丢弃。2. B收到重复的M1后，也直接丢弃重复的M1。
连续ARQ协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

优点：信道利用率高，容易实现，即使确认丢失，也不必重传。

缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。比如：发送方发送了 5条消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

连续ARQ协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

优点：信道利用率高，容易实现，即使确认丢失，也不必重传。

Socket 通信具体原理 (先不看)

https://blog.csdn.net/qq_28865297/article/details/71123832

TCP重传

所以 TCP 针对数据包丢失的情况，会⽤重传机制解决。

接下来说说常⻅的重传机制：

超时重传：

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

TCP 会在以下两种情况发⽣超时重传：
1.数据包丢失
2.确认应答丢失

快速重传（数据驱动，三次ACK）

它不以时间为驱动，⽽是以数据驱动重传。

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

问题：⽐如对于上⾯的例⼦，是重传 Seq2 呢？还是重传 Seq2、 Seq3、 Seq4、 Seq5 呢？因为发送端并不清楚这连续的三个 Ack 2 是谁传回来的。
根据 TCP 不同的实现，以上两种情况都是有可能的。可⻅，这是⼀把双刃剑。
为了解决不知道该重传哪些 TCP 报⽂，于是就有 SACK ⽅法。

SACK（ Selective Acknowledgment 选择性确认）

这种方式需要在 TCP 头部「选项」字段⾥加⼀个 SACK 的东⻄，它可以将缓存的地图发送给发送⽅，这样发送⽅就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。

D-SACK （Duplicate SACK ）

主要使⽤了 SACK 来告诉「发送⽅」有哪些数据被重复接收了。

滑动窗口

我们都知道 TCP 是每发送⼀个数据，都要进⾏⼀次确认应答。当上⼀个数据包收到了应答了，再发送下⼀个。但这种⽅式的缺点是效率⽐较低的。数据包的往返时间越长，通信的效率就越低。而且数据包往返时间越长，通信效率越低。

为解决这个问题， TCP 引⼊了窗⼝这个概念。即使在往返时间较⻓的情况下，它也不会降低⽹络通信的效率

窗口大小就是指⽆需等待确认应答，⽽可以继续发送数据的最⼤值；窗⼝的实现实际上是操作系统开辟的⼀个缓存空间，发送⽅主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。

问题：窗⼝⼤⼩由哪⼀⽅决定

TCP 头⾥有⼀个字段叫 Window ，也就是窗⼝⼤⼩。
这个字段是接收端告诉发送端⾃⼰还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能⼒来发送数据，⽽不会导致接收端处理不过来。
所以，通常窗⼝的⼤⼩是由接收⽅的窗⼝⼤⼩来决定的。

接收窗⼝和发送窗⼝的⼤⼩是相等的吗？

并不是完全相等，接收窗⼝的⼤⼩是约等于发送窗⼝的⼤⼩的。

知道一件事情

发送窗口的大小是根据min(cwnd, awnd)一个是拥塞窗口大小，一个是通知窗口大小，通知窗口大小awnd，TCP通过和接收端交换一个数据包就可以获取。但是cwnd怎么获取呢？获取最佳值的唯一办法就是用越来越快的速率不断发送数据，直到数据包丢失或者网络拥塞为止。其实就是下面的拥塞控制的几种方式。

流量控制

发送⽅不能⽆脑的发数据给接收⽅，要考虑接收⽅处理能⼒。如果⼀直⽆脑的发数据给对⽅，但对⽅处理不过来，那么就会导致触发重发机制，从而导致网络流量的无端的浪费。为了解决这种现象发⽣， TCP 提供⼀种机制可以让「发送⽅」根据「接收⽅」的实际接收能⼒控制发送的数据量，这就是所谓的流量控制。

拥塞控制

总过程：
方式一： 慢启动->拥塞避免阶段->拥塞发生（超时重传,ssthresh变成cwnd / 2, cwnd重置为1）-> 重新进入慢启动，拥塞避免
方式二： 慢启动->拥塞避免阶段->拥塞发生（快速重传，说明网络情况不是特别差，cwnd= cwnd/ 2, ssthresh=cwnd）->进入快速恢复（cwnd -> ssthresh + 3,如果收到重复的ACK信号，cwnd + 1, 如果收到新的ack，说明重复的ACK数据都已经收到，恢复过程已经结束，可以回到恢复之前的状态，也就是再次进入拥塞避免）

前⾯的流量控制是避免「发送⽅」的数据填满「接收⽅」的缓存，但是并不知道⽹络的中发⽣了什么。

⼀般来说，计算机⽹络都处在⼀个共享的环境。因此也有可能会因为其他主机之间的通信使得⽹络拥堵。

在⽹络出现拥堵时，如果继续发送⼤量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是⼀重传就会导致⽹络的负担更重，于是会导致更⼤的延迟以及更多的丢包，这个情况就会进⼊恶性循环被不断地放⼤

于是，就有了拥塞控制，控制的⽬的就是避免「发送⽅」的数据填满整个⽹络。为了在「发送⽅」调节所要发送数据的量，定义了⼀个叫做「拥塞窗⼝」的概念。

发送窗口：swnd

接收窗口：awnd：接收方根据接收缓存设置的值，并告知发送方，反映接收方容量。

拥塞窗口：cwnd：发送方根据自己估算的网络拥塞程度而设置的窗口值，反映网络当前容量。

拥塞窗⼝ cwnd是发送⽅维护的⼀个的状态变量，它会根据⽹络的拥塞程度动态变化的。

拥塞窗⼝ cwnd 变化的规则：
只要⽹络中没有出现拥塞， cwnd 就会增⼤；
但⽹络中出现了拥塞， cwnd 就减少

那么怎么知道当前⽹络是否出现了拥塞呢？

其实只要「发送⽅」没有在规定时间内接收到 ACK 应答报⽂，也就是发⽣了超时重传，就会认为⽹络出现了⽤拥塞。

拥塞控制主要是四个算法：

慢启动

⼀点⼀点的提⾼发送数据包的数量，当发送⽅每收到⼀个 ACK，拥塞窗⼝ cwnd 的⼤⼩就会加 1

拥塞避免

超过慢启动门限后，就会进入拥塞避免算法。

每当收到⼀个 ACK 时， cwnd 增加 1/cwnd。拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长

增长到某一个阶段，网络就会慢慢进入拥塞状况，就会出现丢包现象，就需要对丢失的数据包进行重传。出发了重传机制后，也就进入了拥塞发生算法。

拥塞发⽣

当⽹络出现拥塞，也就是会发⽣数据包重传，重传机制主要有两种：
超时重传
快速重传
这两种使⽤的拥塞发送算法是不同的，接下来分别来说说。

如果是超时重传

此时：初始慢启动门限设置为cwnd / 2;(当前拥塞窗口的一半)，

cwnd重置为1，接着重新开始慢启动（马上回到解放前），这种方式比较激进，反应也很强烈，会造成网络卡顿。

如果TCP重传机制是快速重传

TCP会认为网络没那么糟糕，认为大部分没有丢，只是丢了一小部分。

ssthresh 和 cwnd 变化如下：
cwnd = cwnd/2 ，也就是设置为原来的⼀半;
ssthresh = cwnd ;
进⼊快速恢复算法

快速恢复

快速恢复算法是认为，你还能收到 3 个重复 ACK 说明⽹络也不那么糟糕，所以没有必要像 RTO 超时那么强烈。进入快速恢复以前，cwnd和ssthresh已经被更新了：

cwnd = cwnd/2 ，也就是设置为原来的⼀半;
ssthresh = cwnd ;

然后，进入到快速恢复算法如下：

拥塞窗口 cwnd = ssthresh + 3（ 3 的意思是确认有 3 个数据包被收到了）；

重传丢失的数据包

如果再收到重复的 ACK，那么 cwnd 增加 1；

如果收到新数据的ACK后，可以把cwnd设置为第一步中的ssthresh值，因为ACK确认了新的值，说明从duplicated ACK时的数据都已经收到，恢复过程已经结束，可以恢复到之前的状态，再次进入拥塞避免状态

拥塞算法总示意图

IP基础知识(先不看)

⽆分类地址 CIDR(先不看)

32 ⽐特的 IP 地址被划分为两部分，前⾯是⽹络号，后⾯是主机号。

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

掩码作用：

在上⾯我们知道可以通过⼦⽹掩码划分出⽹络号和主机号，那实际上⼦⽹掩码还有⼀个作⽤，那就是划分⼦⽹。
⼦⽹划分实际上是将主机地址分为两个部分：⼦⽹⽹络地址和⼦⽹主机地址。形式如下：

假设对 C 类地址进⾏⼦⽹划分，⽹络地址 192.168.1.0，使⽤⼦⽹掩码 255.255.255.192 对其进⾏⼦⽹划分。C 类地址中前 24 位是⽹络号，最后 8 位是主机号，根据⼦⽹掩码可知从 8 位主机号中借⽤ 2 位作为⼦⽹号。

子网掩码：网络号和子网号都为1，主机号为0；

IP协议相关技术

DNS域名解析

通常使⽤的⽅式是域名，⽽不是 IP 地址，因为域名⽅便⼈类记忆，DNS 域名解析，将域名⽹址⾃动转换为具体的 IP 地址。

域名的层级关系：

DNS 中的域名都是⽤句点来分隔的，⽐如 www.server.com ，这⾥的句点代表了不同层次之间的界限。

根域是在最顶层，它的下⼀层就是 com 顶级域，再下⾯是 server.com。

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

根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 服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主。

子网掩码练习网络号 = 子网掩码AND IP地址

什么是ARP协议 (Address Resolution Protocol)（网络层）

ARP协议完成了IP地址与物理地址的映射。每一个主机都设有一个 ARP 高速缓存，里面有所在的局域网上的各主机和路由器的 IP 地址到硬件地址的映射表。当源主机要发送数据包到目的主机时，会先检查自己的ARP高速缓存中有没有目的主机的MAC地址，如果有，就直接将数据包发到这个MAC地址，如果没有，就向所在的局域网发起一个ARP请求的广播包（在发送自己的 ARP 请求时，同时会带上想知道的MAC地址的主机IP地址），收到请求的主机检查自己的IP地址是否和ARP请求包中的目标IP是否一致，如果一致就把自己的MAC地址塞入ARP响应包返回给主机。然后源主机收到响应包后，添加目的主机的IP地址和MAC地址的映射，在进行数据传送。

什么是NAT (Network Address Translation, 网络地址转换)？

用于解决内网中的主机要和因特网上的主机通信。由NAT路由器将主机的本地IP地址转换为全球IP地址，分为静态转换（转换得到的全球IP地址固定不变）和动态NAT转换。

HTTP是不保存状态的协议,如何保存用户状态?

常见的有以下两种解决方案：

基于Session实现的会话保持

在会话开始时（客户端第一次像服务器发送http请求），服务器将会话状态保存起来（本机内存或数据库中），然后分配一个会话标识（SessionId）给客户端，这个会话标识一般保存在客户端Cookie中，以后每次浏览器发送http请求都会带上Cookie中的SessionId到服务器，服务器拿到会话标识就可以把之前存储在服务器端的状态信息与会话联系起来，实现会话保持（如果遇到浏览器禁用Cookie的情况，则可以通过url重写的方式将会话标识放在url的参数里，也可实现会话保持）

基于Cookie实现的会话保持

基于Cookie实现会话保持与上述基于Session实现会话保持的最主要区别是前者完全将会话状态信息存储在浏览器Cookie中，这样一来每次浏览器发送HTTP请求的时候都会带上状态信息，因此也就可以实现状态保持。

两者优缺点

基于Session的会话保持优点是安全性较高，因为状态信息保存在服务器端。缺点是不便于服务器的水平扩展。大型网站的后台一般都不止一台服务器，可能几台甚至上百台，浏览器发送的HTTP请求一般要先通过负载均衡器才能到达具体的后台服务器，这就会导致每次HTTP请求可能落到不同的服务器上，比如说第一次HTTP请求落到server1上，第二次HTTP请求落到server2上。而Session默认是存储在服务器本机内存的，当多次请求落到不同的服务器上时，上述方案就不能实现会话保持了（常用解决方案是中间件，例如Redis，将Session的信信息存储在Redis中，这样每个server就都可以访问到）。

基于Cookie的会话保持的优点是服务器不用保存状态信息，减轻服务端存储压力，也便于服务端做水平扩展。缺点是不够安全，因为状态信息是存储在客户端的，这意味着不能在会话中保存机密数据，另一个缺点是每次HTTP请求都需要发送额外的Cookie到服务端，会消耗更多带宽。

Cookie 被禁用怎么办?

URL重写，就是把session id直接附加在URL路径的后面。
最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面。

Cookie的作用是什么?和Session有什么区别？

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

Cookie 一般用来保存用户信息比如①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

HTTP 1.0和HTTP 1.1的主要区别是什么?

1、长连接 : 在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式。

2、错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

3、缓存处理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

4、带宽优化及网络连接的使用 :HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

URI和URL的区别是什么?

URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。
URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

HTTP 和 HTTPS 的区别？

端口：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。

安全性和资源消耗： HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；

非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

打开一个网址的过程，用到的协议

总体来说分为以下几个过程:
1 DNS解析
2 TCP连接
3 发送HTTP请求
4 服务器处理请求并返回HTTP报文
5 浏览器解析渲染页面
6 连接结束

应用层使用了HTTP协议进行超文本传输，对于服务器后台处理应该有telnet远程调用协议响应用户，DNS协议获取网络地址，即IP地址；打开网页，网页显示用到了表示层的HTML协议；
另外必然用到了传输层的TCP和网络层的IP协议；网络层ARP协议获取物理地址（IP地址转化为MAC地址）；ICMP协议控制信息的传递，还有很多吧，我就不知道了

HTTP，TCP，IP，DNS，ARP，ICMP（要对网路连接状况进行判断的时候）必然有

键⼊⽹址到⽹⻚显示，期间发⽣了什么？

总体来说分为以下几个过程:

浏览器解析URL，确定WEB服务器和文件名，根据这些信息生成HTTP请求信息。
DNS解析
TCP连接
客户端发送HTTP请求
服务器处理请求并返回HTTP报文
浏览器解析渲染页面
连接结束

6 计算机网络待更新相关推荐

计算机强化课程计算机网络,大学计算机网络技术课程教学改革
[摘要]在课程体系建设上,要将计算机网络技术课程理论内容与实践应用相结合,在高校应与学生的未来职业生涯建立必然联系.在计算机网络教学理念上,不断开拓思路,合理调整课程体系结构,从而实现课程改革的创新. ...
计算机网络课程背景,课程发展的历史沿革
1. 90年代初,我校在计算机科学专业中将<计算机网络>列为必修课程,其它专业为选修课程,并确定本课程负责人开设该课程.课程负责人即开始收集国内外教材及有关资料. 2. 课程负责人开始讲授 ...
《计算机网络基础》上海交大
课程目录: [上海交大计算机网络基础更新完毕].51.avi 19.06MB [上海交大计算机网络基础更新完毕].50.avi 20.86MB [上海交大计算机网络基础更新完毕].49.avi 25. ...
【图像处理-计算机视觉学习路线】个人记录
学习资料记录常用软件编程: MATLAB 学术科研人手必备,非常常用 PyCharm 开发Python必备 Visual Stuido 开发C++必备 VS Code 浏览C++或Python代码 ...
Cardano(ADA)， EOS, RChain(RHOC), Aeternity(AE) 都是极其好的币
从区块链的基础知识出发,研究ETH和EOS的区别免责声明:EOS目前还在开发中,我们对此项目的一些理解可能会改变.而且,我并不是以太坊开发者,而只是一个喜欢区块链的爱好者.请牢记这两点,请把下面的内 ...
[VFP实例]VFP的OLE技术应用详解
VFP用了OLE2．0技术,使VFP应用程序的适应能力大为加强. VFP提供两种类型的OLE对象:一种是OLE控件(．OCX文件),这是一种自定义控件,通常在WINDOWS/SYSTEM目录下,拥有自 ...
sqlserver数据库错误码
错误严重性是否记录事件说明 -2 超时时间已到. 超时时间在操作完成或服务器没有响应之前已过. (Microsoft SQL Server,错误: -2). -1 在建立与服务器的连接时出错. ...
计算机网络(学习过程中--持续更新)
文章目录一.OSI七层协议.TCP/IP四层协议.五层协议都讲一讲 OSI七层协议 TCP/IP四层协议五层协议图表总结二.TCP.UDP TCP协议 UDP协议 TCP和UDP的区别 TCP ...
计算机网络学习——王道教材书（持续更新）
计算机网络文章目录计算机网络 1.计算机网络体系结构 1.1计算机网络概述 1.1.1计算机网络概念 1.1.2计算机网络组成 1.1.3计算机网络功能 1.1.4计算机网络分类 1.2计算机网络 ...

6 计算机网络 待更新

计算机网络 待更新