五、计算机网络

目录

OSI七层协议

TCP的三次握手和四次挥手

TCP和UDP的区别

TCP 第三次握手失败的情况 TCP 是如何处理的？

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

TCP 是如何保证可靠传输数据的？

TCP滑动窗口

HTTP

get和post请求的区别?

从一个 URL 到获取页面的过程

HTTP1.0和HTTP1.1

HTTP状态码

HTTPS

HTTP和HTTPS的区别

Cookie和Session的区别

session 和 cookie 的关系？禁用 cookie 后对 session 的影响？

---

OSI七层协议

1.物理层：传输比特流，定义物理设备标准。

2.数据链路层：将比特数据组装为帧和点到点传递。( 交换机)

3.网络层：将网络地址翻译成对应的物理地址，决定如何将数据从发送方路由到接受方(路由器；单位是数据包。有IP协议)

4.传输层：解决主机间的数据传输。(传输协议， 流量控制，接收方接收数据快慢程度；还可以分割大的数据包； TCP和UDP协议)

5.会话层：建立、管理和终止会话。( 自动收发包和寻址)

6.表示层：解决不同系统之间的通信语法的问题。

7.应用层：让你更方便地应用从网络中接收到的数据。关注TCP/IP协议中的http协议
 

TCP的三次握手和四次挥手

TCP3次握手： 

第一次握手：客户端向服务器发送同步报文段（SYN），请求建立连接。并进入SYN_SEND状态，等待服务器确认。

第二次握手：服务器收到连接请求报文段后，如果同意建立连接，就向客户端发回确认，此时服务器进入SYN_RECV状态。

第三次握手：当客户端收到确认报文段后，还要向服务器发送确认包ACK，此包发送完毕，客户端和服务器就进入ESTABLISHED状态，完成三次握手。

TCP4次挥手：

第一次挥手：客户端打算关闭连接，就向其TCP发送一个连接释放报文，停止再发送数据，并主动关闭TCP连接。客户端进入FIN_WAIT_1状态。

第二次挥手：服务器收到连接释放报文段后即发出确认。确认序号为收到的序号加1，服务器进入CLOSE_WAIT状态。

第三次挥手：如果服务器已经没有要向客户端发送的数据，就向客户端发送一个FIN数据包，用来关闭服务器与客户端的连接，服务器就进入LAST_ACK状态。

第四次挥手：客户端收到服务器发来的连接释放报文段后，再发回一个报文确认。确认序号为收到序号+1，服务器进入CLOSED状态，完成四次挥手。

为什么是三次握手？

三次握手是为了初始化Sequence Number的初始值，并作为以后数据通信的序号，以保证应用层接收到的数据不会因为网络上的传输问题而乱序。

如果是两次的话，客户端和服务器的初始序列号将无法达成一致。

协议没有100％可靠的，所以三次就够了，如果是四次也不能保证是100%可靠的。

 

TCP和UDP的区别

1、（面向连接vs无连接）TCP是面向连接的通讯协议（三次握手；四次挥手），UDP是面向无连接的通讯协议。

2、（可靠性）TCP有交付保证，如果消息在传输中丢失，那么它将重发；udp没有交付保证，一个数据包在运输过程中可能丢失。

3、（有序性）TCP利用序列号保证消息的顺序交互，UDP不保证有序性

4、（速度）tcp速度慢，适合传输大量数据；udp速度快，适合传输少量数据。

5、（重量级vs轻量级）TCP要求系统资源较多，UDP要求系统资源较少。
 

TCP 第三次握手失败的情况 TCP 是如何处理的？

第三次失败，只有客户端处于成功状态（因为第 2 次服务器返回了 ACK），服务器端没有接收到客户端的 ACK。这要分几种情况讨论：

• 客户端发出的 ACK 丢失了，发出的下一个数据包没有丢失，则服务端接收到下一个数据包（这个数据包里也会带上 ACK 信息），能够进入正常的 ESTABLISHED 状态
• 如果服务端和客户端都没有数据发送，或者服务端想发送数据（但是发不了，因为没有收到客户端的 ACK），服务器都会有定时器发送第二步 SYN+ACK 数据包，如果客户端再次发送 ACK 成功，建立连接。
• 如果一直不成功，服务器肯定会有超时设置，超时之后会给客户端发 RTS 报文，进入 CLOSED 状态，防止 SYN 洪泛攻击。

 

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

TCP 是全双工模式，关闭连接时，当服务器收到客户端的 FIN 报文时，仅仅表示客户端不再发送数据了但是还能接收数据。此时，服务器也未必全部数据都发送给客户端了，所以服务器可以立即 close；也可以发送一些数据给客户端后，再发送 FIN 报文给对方来表示同意现在关闭连接，所以它这里的ACK报文和FIN报文大多数情况下都是分开发送的。

 

TCP 是如何保证可靠传输数据的？

保证可靠稳定的传输最主要是通过： 拥塞控制、流量控制、ARQ 协议
除此之外还有：超时传送、丢弃重复、校验和分割合适数据包

拥塞控制主要有四个方法：

• 慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小；
• 拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
• 快重传：快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文 段，而不必继续等待设置的重传计时器时间到期。
• 快恢复：当发送方知道了只是丢失了个别报文段使，不会使用慢开始，而是使用快恢复来设置阻塞窗口的值，并开始执行拥塞避免算法。

流量控制

一般我们都希望发送数据的速度尽可能快，但如果发送数据的速度过快，接收端来不及接收，就可能导致数据丢失的问题。所谓流量控制，就是根据接收端的接收能力，动态地调整发送端的发送速度，确保接收端来的及接收。流量控制主要是通过滑动窗口机制实现的。

ARQ 协议

即ARQ automatic repeat request，自动重传请求，接收端不需要向发送端发送重传请求，当超过指定时间时发送端会自动进行超时重传。

TCP滑动窗口

       

RTT：发送一个数据包到收到对应的ACK所花费的时间
RTO：重传时间间隔

TCP使用滑动窗口做流量控制与乱序重排

TCP滑窗可靠性，建立在确认重传基础上。

发送窗口只有收到接收端对于本段发送窗口的ACK确认，才移动滑窗左边界。

接收窗口只有在前面所有的段都确认之后，才会移动滑窗左边界。

如果接收方前面还有数据未接收，后面收到数据，不会移动滑窗。确保发送方重传后面的数据。

首先send端 发送一个大小为5 的数据信息，假设我们的窗口就是5，接受端回复一个ack = 3.这时候说明我们只成功发送了三个，send端会发送接着将4、5数据发送过去。send端这个时候滑动窗口向右移动三位。接收端接受确认了三个，也会向右移动三位

 

HTTP

结构：

HTTP报文分为HTTP请求报文和响应报文，请求报文由请求行（请求方法，请求资源的URL和HTTP的版本）、首部行和实体（通常不用）组成。响应报文由状态行（状态码，短语和HTTP版本）、首部行和实体（有些不用）组成。

主要特点：

• 支持客户、服务器模式
• 简单快速：客户端向服务器请求服务时只需传送请求方法和路径，请求方法常用的有GET、HEAD、POST，由于http协议简单，使得http服务程序的规模小，因而通讯速度快
• 灵活：Http允许传输任一类型的数据对象，正在传输的类型由ContentType加以标记
• 无连接：限制每次链接只处理一个请求，服务器处理完客户的请求，并收到客户的应答，则断开链接，采用这种方式可以节省传输时间。
• 无状态：对事务处理没有记忆能力，传送前的状态未知。

get和post请求的区别?

 GET 方法从服务器获取资源，POST 是向服务器发送数据

①安全性：POST的安全性要比GET的安全性高。Get请求提交的数据会在地址栏显示出来，而post请求不会再地址栏显示出来。

②传输数据的大小：http Get请求由于浏览器对地址长度的限制而导致传输的数据有限制。而POST请求不会因为地址长度限制而导致传输数据限制。
 

从一个 URL 到获取页面的过程

1、首先进行DNS解析，解析URL所对应的ip地址

2、发起TCP的3次握手

3、建立TCP连接后，浏览器发起http请求

4、服务器响应http请求，浏览器得到html代码

5、浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）

6、浏览器对页面进行渲染呈现给用户

 

HTTP1.0和HTTP1.1

HTTP1.0使用的是非持续连接，每次请求文档就有2倍的RTT开销，另外客户和服务器每一次建立新的TCP连接都要分配缓存和变量，这种非持续连接会给服务器造成很大的压力。

HTTP1.1使用的是持续连接，服务器会在发送响应后在一段时间内继续保持这条连接，使同一个浏览器和服务器可以继续在这条连接上传输后续的HTTP请求和响应报文。HTTP1.1的持续连接有两种工作方式，非流水线和流水线方式。非流水线方式就是客户在收到前一个响应后才能发送下一个请求，流水线方式是客户收到响应前就能连着发送新的请求。

 

HTTP状态码

401 （未授权） 请求未经授权。对于需要登录的网页，服务器可能返回此响应。
403 （禁止） 服务器拒绝请求。
404 （未找到） 服务器找不到请求的网页。

502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。

常见的HTTP状态码以及错误分析

 

HTTPS

特点

HTTP有很大的安全隐患：使用明文进行通信，内容可能会被窃听。不验证通信方的身份，通信方的身份有可能遭遇伪装。无法证明报文的完整性，报文有可能遭篡改。

HTTPS是以安全为目标的HTTP通道，S代表security，让HTTP先和SSL通信，再由SSL和TCP 通信，也就是说 HTTPS使用了隧道进行通信。通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

HTTPS数据传输流程

1. 浏览器告诉服务器，我支持哪些算法
2. 服务器选择一种算法，把自己的证书发给浏览器
3. 浏览器检查证书是否合法，并用证书中的公钥对随机生成的消息进行加密
4. 服务器用私钥解密消息，验证哈希，加密响应消息发给浏览器
5. 浏览器解密响应消息，如果跟之前发过去的哈希值一致，那么就用之前生成的随机密码加密。

HTTPS真的安全吗？

• HTTPS并不是真正的安全，如果在浏览器地址栏只输入网址，不输入协议，浏览器就会默认填充http：//，会有被劫持的风险。
• 可以使用HSTS优化

 

HTTP和HTTPS的区别

• HTTPS需要到CA申请证书，HTTP不需要
• HTTPS密文传输，HTTP明文传输
• 连接方式不同，默认端口也不一样。HTTPS默认使用443端口，HTTP使用80端口
• HTTPS=HTTP+加密+认证+完整性保护，较HTTP安全

 

Cookie和Session的区别

• cookie数据存放在客户的浏览器上，session数据放在服务器上。
• cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session。
• session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie。

 

session 和 cookie 的关系？禁用 cookie 后对 session 的影响？

Session 的实现常常依赖于 Cookie 机制。一般默认情况下，在会话中，服务器存储 session 的 sessionid 是通过 cookie 存到浏览器里。如果浏览器禁用了 cookie，浏览器请求服务器无法携带 sessionid，服务器也就无法识别请求中的用户身份，session就会失效。

但是可以通过其他方法在禁用 cookie 的情况下，可以继续使用 session。

• 通过 url 重写，把 sessionid 作为参数追加的原 url 中，后续的浏览器与服务器交互中携带 sessionid 参数。
• 服务器的返回数据中包含 sessionid，浏览器发送请求时，携带 sessionid 参数。
• 通过 Http 协议其他 header 字段，服务器每次返回时设置该 header 字段信息，浏览 器中 js 读取该 header 字段，请求服务器时，js 设置携带该 header 字段。