http、TCP/IP、https理解与简单延伸

HTTP

看到比较通俗又准确的描述应该是这个:HTTP是在计算机世界里专门为两点之间传输文字、图片、视频、音频等超文本数据的约定和规范

有个关键概念是:数据在两点间传输,但是中间允许有“中转”或者“接力”,只要不打扰基本的数据传输,就可以添加任意的额外功能,例如安全认证、数据压缩、编码转换等等,优化整个传输过程。所以才有http加一层验证,优化成https

类比的话,有点像我们一个新项目,要制定接口文档,制定接口请求方式和报文格式,这叫约定与规范。

具体约定了什么,有很多,前端比较关注大概就是:

  • 约定了状态码
  • 2xx开头的表示“成功处理了请求”,比如200
  • 3xx开头的表示“未完成请求,需要进一步操作”,比较常见的是304 Not Modified
  • 4xx开头的表示“请求错误,服务端无法处理”,比如404 Not Found, 403 Forbidden,401 Not Authorized
  • 5xx开头表示“服务器本身错误”,比如500 interal Server Error
  • 约定了HTTP请求方法,GET、POST、PUT、DELTE,其中四种方法各有异同,比较需要关注的是GET与POST的区别,比较出名的是GET的参数长度是有限制的,POST请求体里没有,当然GET也能带body请求体,但不一定会被服务端接收到,
  • 约定了Header,比如之前文章提及到的协商缓存强缓存的实现,是基于这么个规范实现的
    ...

TCP/IP

HTTP只是一个规范,而这个规范的具体apply,就需要往下看到TCP/IP层了,也就是"HTTP over TCP/IP"的概念

IP即Internet Protocol,也就是我们经常看到的“192.168.x.x”,解决寻址和路由问题,相当于地址、门牌号。使用IP地址这个概念定位互联网这张大网上每一台机器

这里可以扩展下IPv4和IPv6

  • IPv4,格式类似于"192.168.0.1"四组数字,每组数字取值范围是0~255,也就是256个数,2的8次方,那么四组,也就是2的32次方,这也就意味着IPv4的总共“门牌号”只有2的32次方个,不足以满足当前互联网地址要求(越来越多),所以才有IPv6(当然,IPv4能用这么久有原因了,其一是NAT(Network Address Translation,网络地址转换)技术,即一个公网地址供给一个小局域网使用,这样几十上百台电脑在同一个小局域网内也可以只需要一个公网地址了
  • IPv6,格式类似于“2001:0db8:85a3:08d3:1319:8a2e:0370:7344”,别蒙,解释下来就知道了。较之前的四组,改成分为了八组,每组包含4位数,而这四位数用十六进制,这也就是为什么会出现字母了,那么就可以进行计算,地址扩容后可以达到:2的4次方(即16,一位数)4次相乘(四位数),得出的数是2的16次方,有8组,8次相乘,即2的(16乘8)次方,2的128次方个地址。除了地址扩容,其优点和省略写法可以自行搜寻,此文推荐

讲完IP就到TCP了,即"Transmission Control Protocol",即也是一种协议标准,其实现,最著名就是“TCP三次握手”了。

要理解其内容,得先明了其目的,之所以有三次握手,是为了保证:报文传输给了对的人(点),且对应的人(点)接收、发送能力正常

目的知道了,来看内容。一个TCP报文如下


image.png

而在“握手”(即发包到接收的过程)过程里,需要特别关注的地方在

image.png
  • 第一次握手,源主机会发送
    位码SYN(即synchronous,建立连接)=1
    序列号seq(随机的),用x表示
    到目标主机(一般为服务器)

  • 第二次握手,目标主机收到请求后,要确认连接建立,向源主机发送ACK(acknowledgement,即确认码),这个码的值为一次握手的seq序列号x+1,同时SYN位码、ACK位码设为1,且产生对应发送出去的序列号seq,此处用y表示

  • 第三次握手,源主机会收到第二次握手发来的报文,此时会看:ACK位码为1且SYN位码也为1,那么“有可能”是我之前发的第一次握手的“要求确认报文”,就去看ack number,校验是不是之前发的seq序列号 x+1,正确的话,源主机会生成一个新的、第三次握手发送的报文,此时ACK位码为1,SYN位码为0,ack number为第二次握手产生的序列号y+1,再发送给目标主机

其实没必要硬背,了解场景和限制,就能很快理解

互联网是张很大的网,每个网的节点有可能是发送者也可能是接受者,而报文传输规范了报文的结构(比如有确认号seq、SYN位、ACK位等等),即报文传输结构基本是固定的,而同一时间段内,某一个节点有可能会接收到N条报文,那么就需要一套机制来保证:

  • 报文传输不会传岔(1000条报文同时过来,能准确知道这1000条对应的是哪里来的、是用来干什么的;或者是网络堵塞、延迟等)
    哪里来(源端口、目的端口等)。用来干什么(SYN,为1,则为“用来确认连接的”。ACK,为1,则为"是确认的报文",两者有机结合,对应的就是TCP三次握手的服务端确认报文(SYN=1, ACK=1)以及客户端确认报文(SYN=0, ACK=1))
  • 准确知道报文是干嘛的

然后回过头去想,就比较简单了

推荐结合阅读这篇文章及这篇文章

内有TCP四次挥手流程,自行阅读

理解了TCP三次握手,就可以来看https了,其实就是加一层

image.png

而https验证阶段如下

image.png
    1. 客户端发起HTTPS请求
    1. 服务端的配置
    1. 传送证书
    1. 客户端解析证书
    1. 传送加密信息
    1. 服务段解密信息
    1. 传输加密后的信息
    1. 客户端解密信息

推荐阅读

引申可以回答这么一个问题了:当浏览器键入地址,到渲染页面,中间发生了什么?

  1. 域名解析
  2. 发起TCP的三次握手
  3. 建立起TCP连接后发起http请求
  4. 服务器响应http请求,浏览器得到html代码
  5. 浏览器解析html代码,并请求html代码中的资源(css JavaScript 图片)
  6. 浏览器对页面进行渲染呈现

推荐阅读

你可能感兴趣的:(http、TCP/IP、https理解与简单延伸)