计算机网络

计算机网络
计算机网络

get与post

2020年了，还是要问的。

从标准上看：
GET 用于获取信息，是无副作用的，是幂等的，且可缓存
POST 用于修改服务器上的数据，有副作用，非幂等，不可缓存

报文上的区别：
GET 和 POST 只是 HTTP 协议中两种请求方式，而 HTTP 协议是基于 TCP/IP 的应用层协议，无论 GET 还是 POST，用的都是同一个传输层协议，所以在传输上，没有区别。
报文格式上，不带参数时，最大区别就是第一行方法名不同。
带参数时，GET 方法的参数应该放在 url 中，POST 方法参数应该放在 body 中。

http请求与响应

https默认请求端口443， http默认80

  • 请求行：包括请求的方法，路径和协议版本
  • 请求头：包含了请求的一些附加的信息，一般是以键值的形式成对存在，比如设置请求文件的类型accept-type，以及服务器对缓存的设置。
  • 空行

  • 请求主体：对于post请求，所需要的参数都不会放在url中，这时候就需要一个载体了，这个载体就是请求主体

  • 响应行：包含了协议版本，与请求的起始行不同的是其包含的还有状态码和状态码的原因短语。

  • 响应头
  • 空行
  • 报文主体：请求所需要的资源

从输入url到页面展现发生了什么

  • 域名解析查找服务器IP
  • 通过IP向服务器发起TCP连接
  • 向服务器发起请求
  • 服务器返回请求内容
  • 浏览器解析渲染页面
  • 关闭连接

常见http状态码

  • 200 OK
  • 301 永久重定向
  • 302 临时重定向
  • 304 no modify 说明这次请求的资源在上次请求之后没有改变，浏览器（客户端）可以直接从它的缓存中取资源
  • 400 bad request 服务器不知道怎么应答
  • 403 请求资源被服务器拒绝
  • 404 not found
  • 500 服务器故障

TCP/IP与Http协议的区别与关系

TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。

我们在传输数据时，可以只使用（传输层）TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用到应用层协议，应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。WEB使用HTTP协议作应用层协议，以封装HTTP 文本信息，然后使用TCP/IP做传输层协议将它发到网络上。

“IP”代表网际协议，TCP和UDP使用该协议从一个网络传送数据包到另一个网络。把IP想像成一种高速公路，它允许其它协议在上面行驶并找到到其它电脑的出口。TCP和UDP是高速公路上的“卡车”，它们携带的货物就是像HTTP，文件传输协议FTP这样的协议等。

在 HTTP/1.0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 链接。但是这样代价很大，每个请求都要多花一段时间。
可以通过设置服务器对Connection：keep-alive的支持，来使得tcp连接可以被重新使用。

HTTP/1.1 就把 Connection 头写进标准，并且默认开启持久连接，除非请求中写明 Connection: close，那么浏览器和服务器之间是会维持一段时间的 TCP 连接，不会一个请求结束就断掉。

HTTP/1.1 存在一个问题，单个 TCP 连接在同一时刻只能处理一个请求，意思是说：两个请求的生命周期不能重叠，任意两个 HTTP 请求从开始到结束的时间在同一个 TCP 连接里不能重叠。（实际上定义了Pipelining管道，来提供连续请求的目的，但是浏览器默认关闭，因为实现会有问题）

那么怎么在1。1下解决这个问题呢？（比方说一个页面有很多元素，不可能说顺序一个一个请求，加载，这样很慢）
通过和服务器建立多个tcp连接，然后每个连接上顺序请求。（多路复用）

在 HTTP2 中由于 Multiplexing 特点的存在，多个 HTTP 请求可以在同一个 TCP 连接中并行进行。

RPC与http的区别

首先RPC可以直接建立在tcp上，也可以建立在http上（应用层里面不一定只有一层），甚至还可以建立在自己创建的tcp（传输层协议）之上。

RPC主要用在比较大型的企业里面，对于效率的要求比较高，所以需要使用rpc在应用的发现、负载均衡等等这些特性。

HTTP和HTTPS的区别以及https实现过程

https是http加上ssl安全套接字层(secure socket layer)，可以建立一个信息安全通道，并且能确认网站的真实性。

https实现过程：

对称加密：加密解密使用同一把秘钥。非对称加密：客户端请求使用公钥加密，服务端使用私钥进行解密。公钥谁都可以知道，私钥只有服务端自己知道。

https是两种都用，简单的说，先使用非对称加密来传输一个秘钥（客户端向服务端传，说我们以后都用这个秘钥加密），然后就可以用这个只有客户端和服务端知道的秘钥进行信息加密传输了。

过程：

  • 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件列表（所使用的加密算法及密钥长度等）。
  • 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的（先确定我们要用什么算法，比方说RSA）。
  • 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。把服务器的CA证书给客户端看看。
  • 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
  • SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
  • 接着客户端继续发送 Change Cipher Spec(改变加密策略) 报文。该报文会提示服务器，在此报文之后的通信会采用上一步传递的密钥加密。
  • 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
  • 服务器同样发送 Change Cipher Spec 报文。
  • 服务器同样发送 Finished 报文。
  • 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接。

TCP如何保证可靠传输

  • 校验和:TCP在发送报文之前，发送方要计算校验和，收到数据后，接收方也要计算校验和，如果校验和不相等则丢弃。
  • 序列号与确认应答：
    • 序列号：tcp为传送的字节进行了编号
    • 确认应答：接收方接收到报文之后，会返回ACK确认报文，其中包含一个确认号字段ack，告诉发送方ack之前的数据已经正确接受了，之后要从ack的地方开始发送。
  • 超时重传：发送一个报文如果在一段时间内没有收到确认报文ACK，就会启动超时重传。这保证了tcp在网络延迟或者ACK确认报文丢失的情况下的可靠传输。
  • 三次握手与四次挥手
  • 流量控制与拥塞控制

浏览器渲染

  • 根据HTML文件构件DOM(document object model)

DOM 是 Web 页面的内部的逻辑树文档结构，Web 开发人员可以通过 JavaScript 脚本与之交互数据，以及通过标准 API 来操作 DOM 节点。

  • 子资源加载

在解析构建的DOM时，请求包括图片、css和js之类的外部资源。

  • 样式渲染 使用css渲染DOM样式
  • 布局layout