前端须知的网络知识(TCP/UDP/HTTP/HTTPS...)

本文整理自网络,是自己在学习巩固网络相关知识点时整理的笔记,学习过程中自己思考的一些疑问点也边查询资料边汇总。本文主要涉及TCP/UDP、HTTP发展史、HTTPS、WebSocket、DNS、网络模型。

TCP vs UDP

TCP/IP协议是一个协议簇。里面包括很多协议的,UDP只是其中的一个, 之所以命名为TCP/IP协议,因为TCP、IP协议是两个很重要的协议,就用他两命名了。
TCP/IP协议集包括应用层,传输层,网络层,网络访问层。

TCP

概述

TCP(Transmission Control Protocol,传输控制协议)是面向连接的协议,也就是说,在收发数据前,必须和对方建立可靠的连接。 一个TCP连接必须要经过三次“对话”才能建立起来

名词解释
  • ACK 是TCP报头的控制位之一,对数据进行确认。确认由目的端发出, 用它来告诉发送端这个序列号之前的数据段都收到了。 比如确认号为X,则表示前X-1个数据段都收到了,只有当ACK=1时,确认号才有效,当ACK=0时,确认号无效,这时会要求重传数据,保证数据的完整性。
  • SYN 同步序列号,TCP建立连接时将这个位置1。
  • FIN 发送端完成发送任务位,当TCP完成数据传输需要断开时,提出断开连接的一方将这位置1。
TCP三次握手过程
  • 第一次握手:主机A通过向主机B 发送一个含有同步序列号的标志位的数据段给主机B,向主机B 请求建立连接,通过这个数据段, 主机A告诉主机B 两件事:我想要和你通信;你可以用哪个序列号作为起始数据段来回应我。
  • 第二次握手:主机B 收到主机A的请求后,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A,也告诉主机A两件事:我已经收到你的请求了,你可以传输数据了;你要用那个序列号作为起始数据段来回应我
  • 第三次握手:主机A收到这个数据段后,再发送一个确认应答,确认已收到主机B 的数据段:"我已收到回复,我现在要开始传输实际数据了,这样3次握手就完成了,主机A和主机B 就可以传输数据了。
3次握手的特点

没有应用层的数据 ,SYN这个标志位只有在TCP建立连接时才会被置1 ,握手完成后SYN标志位被置0。

三次握手的作用
  • 确认双方的接受能力、发送能力是否正常。
  • 指定自己的初始化序列号,为后面的可靠传送做准备。
  • 如果是 HTTPS 协议的话,三次握手这个过程,还会进行数字证书的验证以及加密密钥的生成。
TCP建立连接要进行3次握手,而断开连接要进行4次(为什么TCP协议终止链接要四次?)

1、当主机A确认发送完数据且知道B已经接受完了,想要关闭发送数据口(当然确认信号还是可以发),就会发FIN给主机B(将控制位FIN置1,提出停止TCP连接的请求 )。
2、主机B收到A发送的FIN,表示收到了,就会发送ACK回复(将ACK置1)。
3、但这是B可能还在发送数据,没有想要关闭数据口的意思,所以FIN与ACK不是同时发送的,而是等到B数据发送完了,才会发送FIN给主机A(将FIN置1 )。
4、A收到B发来的FIN,知道B的数据也发送完了,回复ACK(将FIN置1 ), A等待2MSL以后,没有收到B传来的任何消息,知道B已经收到自己的ACK了,A就关闭链接,B也关闭链接了。

A为什么等待2MSL,从TIME_WAIT到CLOSE?

在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。

为什么不能两次握手能进行连接?

我们知道,3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。

UDP

1、UDP是一个非连接的协议,传输数据之前源端和终端不建立连接, 当它想传送时就简单地去抓取来自应用程序的数据,并尽可能快地把它扔到网络上。 在发送端,UDP传送数据的速度仅仅是受应用程序生成数据的速度、 计算机的能力和传输带宽的限制; 在接收端,UDP把每个消息段放在队列中,应用程序每次从队列中读一个消息段。
2、 由于传输数据不建立连接,因此也就不需要维护连接状态,包括收发状态等, 因此一台服务机可同时向多个客户机传输相同的消息。
3、UDP信息包的标题很短,只有8个字节,相对于TCP的20个字节信息包的额外开销很小。
4、吞吐量不受拥挤控制算法的调节,只受应用软件生成数据的速率、传输带宽、 源端和终端主机性能的限制。
5、UDP使用尽最大努力交付,即不保证可靠交付, 因此主机不需要维持复杂的链接状态表(这里面有许多参数)。
6、UDP是面向报文的。发送方的UDP对应用程序交下来的报文, 在添加首部后就向下交付给IP层。既不拆分,也不合并,而是保留这些报文的边界, 因此,应用程序需要选择合适的报文大小。

小结TCP与UDP的区别:

1、基于连接与无连接;
2、对系统资源的要求(TCP较多,UDP少);
3、UDP程序结构较简单;
4、流模式与数据报模式 ;
5、TCP保证数据正确性,UDP可能丢包;
6、TCP保证数据顺序,UDP不保证。

TCP和UDP协议的一些应用

TCP和UDP的区别
网络TCP建立连接为什么需要三次握手而结束要四次

HTTP发展史

HTTP 0.9 只有get请求

HTTP 1.0

优化点:

  • 增加了post命令和head命令
  • HTTP请求和回应的格式也变了
  • 支持发送任何格式的内容
  • 其他的新增功能还包括状态码(status code)、多字符集支持、多部分发送(multi-part type)、权限(authorization)、缓存(cache)、内容编码(content encoding)等。

缺点:

  • 连接无法复用。浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接(即每次都需要进行TCP三次握手),服务器不跟踪每个客户也不记录过去的请求。(有些浏览器在请求时,用了一个非标准的Connection字段,Connection: keep-alive,但是,这不是标准字段,不同实现的行为可能不一致)
  • Head-Of-Line Blocking(HOLB,队头阻塞)。HOLB 是指一系列包(package)因为第一个包被阻塞;HOLB 会导致在达到最大请求数量时,剩余的资源需要等待其它资源请求完成后才能发起请求。

HTTP 1.1

1997 年 1 月,发布 HTTP/1.1 版本,只比 1.0 版本晚了半年。直到现在还是最流行的版本。
优化点:

  • 缓存处理。引入了更多的缓存控制策略例如 Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
  • 带宽优化及网络连接的使用。在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。
  • 错误通知的管理。在HTTP1.1中新增了24个错误状态响应码。
  • Host头处理,在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。
  • 长链接。引入了持久连接(persistent connection),即TCP连接默认不关闭,可以被多个请求复用,不用声明Connection: keep-alive。(目前,对于同一个域名,大多数浏览器允许同时建立6个持久连接。)
  • 1.1版还新增了许多动词方法:PUT、PATCH、HEAD、 OPTIONS、DELETE。

缺点:

  • 虽然加入 keep-alive 可以复用一部分连接,但域名分片等情况下仍然需要建立多个 connection,耗费资源,给服务器带来性能压力。
  • HTTP 1.1 尝试使用 pipeling 来解决队头阻塞问题,即浏览器可以一次性发出多个请求(同个域名、同一条 TCP 链接)。但 pipeling 要求返回是按序的,那么前一个请求如果很耗时(比如处理大图片),那么后面的请求即使服务器已经处理完,仍会等待前面的请求处理完才开始按序返回。
  • header 里携带的内容过大,在一定程度上增加了传输的成本,并且每次请求 header 基本不怎么变化,尤其在移动端增加用户流量。

HTTP 2.0

SPDY是2012年谷歌推出的是基于SSL/TLS的传输协议,SPDY有降低延迟,多路复用,头部压缩,服务端推送等特点,这些特点也称为了后续HTTP2.0的功能基石,HTTP2.0是SPDY/3 draft的优化版。

HTTP2.0 与 SPDY的区别:

HTTP2.0 头部压缩采用HPACK, 而SPDY采用DELEFT。
HTTP2.0 理论上支持明文HTTP传输,而SPDY强制使用HTTPS。

SPDY 协议是在 TCP 协议之上。

  • 相比 HTTP/1 的文本格式,HTTP/2 采用二进制格式传输数据,解析起来更高效。
  • 同时,还支持对 Header 压缩,减少头部的包体积大小。
  • HTTP 2.0 还引入了多路复用技术。多路复用很好地解决了浏览器限制同一个域名下的请求数量的问题,同时也更容易实现全速传输,毕竟新开一个 TCP 连接都需要慢慢提升传输速度。


    image.png

HTTP 3.0

TCP 协议虽然能保证不丢包,但还是存在一些局限性。谷歌为了提高Web联网的速度决定推倒重来,吸收 TCP 快速打开的技术,缓存当前会话的上下文等优点,基于 UDP 协议研发一种名为QUIC (全称是“快速UDP互联网连接”)的实验性网络协议

Quic

Quic 全称 quick udp internet connection,“快速 UDP 互联网连接”,(和英文 quick 谐音,简称“快”)是由 google 提出的使用 udp 进行多路并发传输的协议。它不但具有TCP的可靠性、拥塞控制、流量控制等,且在TCP协议的基础上做了一些改进,比如避免了队首阻塞;另外,QUIC协议具有TLS的安全传输特性,实现了TLS的保密功能,同时又使用更少的RTT建立安全的会话。
Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势:

  • 减少了 TCP 三次握手及 TLS 握手时间。
  • 改进的拥塞控制。
  • 避免队头阻塞的多路复用。
  • 连接迁移。
  • 前向冗余纠错。

科普:QUIC 协议原理分析

HTTP相关问题

每次 HTTP 都需要三次握手吗?

HTTP协议是在TCP协议之上的,所以建立一个HTTP连接就需要一次三次握手的过程。但是HTTP有持续连接和非持久连接的区分,就是HTTP请求首部里面的Connection字段,如果是Connection:Keep-Alive就表示持续连接,除非一方主动断开,客户端和服务器的网络连接是持续的,也就是多个HTTP请求都是这一个网络连接;如果是Connection:close,一个HTTP请求在获得HTTP响应后连接就会断开,在下一次HTTP请求时就会有另外一次HTTP连接,也就会再有一个三次握手的过程。http 1.1中默认启用Keep-Alive,如果加入"Connection: close ",才关闭。

什么是长链接

HTTP1.1规定了默认保持长连接(HTTP persistent connection ,也有翻译为持久连接),数据传输完成了保持TCP连接不断开(不发RST包、不四次握手),等待在同域名下继续用这个通道传输数据;相反的就是短连接。

长连接的过期时间

客户端的长连接不可能无限期的拿着,会有一个超时时间,服务器有时候会告诉客户端超时时间,譬如:



上图中的Keep-Alive: timeout=20,表示这个TCP通道可以保持20秒。另外还可能有max=XXX,表示这个长连接最多接收XXX次请求就断开。对于客户端来说,如果服务器没有告诉客户端超时时间也没关系,服务端可能主动发起四次握手断开TCP连接,客户端能够知道该TCP连接已经无效;另外TCP还有心跳包来检测当前连接是否还活着,方法很多,避免浪费资源。

浏览器并发连接的数量限制

RFC文档说,客户端与服务器最多就连上两通道,但服务器、个人客户端要不要这么做就随人意了,有些服务器就限制同时只能有1个TCP连接,导致客户端的多线程下载(客户端跟服务器连上多条TCP通道同时拉取数据)发挥不了威力,有些服务器则没有限制。浏览器客户端就比较规矩,限制了同域名下能启动若干个并发的TCP连接去下载资源。(在HTTP1.x中,并发多个请求需要多个TCP连接,浏览器为了控制资源会有6-8个TCP连接都限制)
并发数量的限制也跟长连接有关联,打开一个网页,很多个资源的下载可能就只被放到了少数的几条TCP连接里,这就是TCP通道复用(长连接)。如果并发连接数少,意味着网页上所有资源下载完需要更长的时间(用户感觉页面打开卡了);并发数多了,服务器可能会产生更高的资源消耗峰值。浏览器只对同域名下的并发连接做了限制,也就意味着,web开发者可以把资源放到不同域名下,同时也把这些资源放到不同的机器上,这样就完美解决了。

HTTP 2.0 服务端推送

请求不是来自客户端“明确”的请求,是从服务端PUSH_PROMISE帧中提供。例如我们加载index.html, 我们可能还需要index.js, index.css等文件。传统的请求只有当拿到index.html,解析html中对index.js/index.css的引入才会再请求资源加载,但是通过服务端数据,可以提前将资源推送给客户端,这样客户端要用到的时候直接调用即可,不用再发送请求。

  • push的资源能缓存在浏览器中
  • 不同的网页能使用该缓存,不用重新发起
  • push的资源通过multiplexed进行传输
  • push的资源能够进行priority标识
  • client有权取消push资源的加载
  • push的资源必须同域

容易混淆的概念

TCP的KeepAlive和HTTP的Keep-alive:
  • “KeepAlive”,TCP的keep alive是检查当前TCP连接是否活着,是为了保证连接是健康的,如即时通讯技术需要用到;TCP keep alive的表现:当一个连接“一段时间”没有数据通讯时,一方会发出一个心跳包(Keep Alive包),如果对方有回包则表明当前连接有效,继续监控。
  • “Keep-Alive”, HTTP的Keep-alive是要让一个TCP连接活久点,为了连接复用,即减少多余的TCP请求。
TCP复用和HTTP复用

TCP复用:TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端TCP连接上。
HTTP复用(HTTP多路复用技术):一个客户端的多个HTTP请求通过一个TCP连接进行处理。
前者是负载均衡设备的独特功能;而后者是HTTP 1.1协议所支持的新功能,目前被大多数浏览器所支持。

TCP复用

TCP连接复用技术通过将前端多个客户的HTTP请求复用到后端与服务器建立的一个TCP连接上。这种技术能够大大减小服务器的性能负载,减少与服务器之间新建TCP连接所带来的延时,并最大限度的降低客户端对后端服务器的并发连接数请求,减少服务器的资源占用。
采用TCP连接复用技术后,客户端(如:ClientA)与负载均衡设备之间进行三次握手并发送HTTP请求。负载均衡设备收到请求后,会检测服务器是否存在空闲的长连接,如果不存在,服务器将建立一个新连接。当HTTP请求响应完成后,客户端则与负载均衡设备协商关闭连接,而负载均衡则保持与服务器之间的这个连接。当有其它客户端(如:ClientB)需要发送HTTP请求时,负载均衡设备会直接向与服务器之间保持的这个空闲连接发送HTTP请求,避免了由于新建TCP连接造成的延时和服务器资源耗费。

HTTP流水线技术(HTTP 1.1)与HTTP多路复用技术(HTTP 2.0)
HTTP 流水线技术

HTTP 1.1 流水线技术9(HTTP pipelining,也有翻译为管道化连接),它是指,在一个TCP连接内,多个HTTP请求可以并行,下一个HTTP请求在上一个HTTP请求的应答完成之前就发起。
由于要求服务端返回响应数据的顺序必须跟客户端请求时的顺序一致,这样也就是要求FIFO,这容易导致队头阻塞(Head-of-line blocking):第一个请求的响应发送影响到了后边的请求,因为这个原因导致HTTP流水线技术对性能的提升并不明显。(前一个请求如果很耗时,那么后面的请求即使服务器已经处理完,仍会等待前面的请求处理完才开始按序返回)

HTTP多路复用技术

在 HTTP/2 中,有两个非常重要的概念,分别是帧(frame)和流(stream)。帧代表着最小的数据单位,每个帧会标识出该帧属于哪个流,流也就是多个帧组成的数据流。
多路复用,就是在一个 TCP 连接中可以存在多条流。在复用同一个TCP连接时,服务器同时/先后收到了A、B两个请求,先回应A请求,但由于处理过程非常耗时,于是服务端就把已经处理好的部分先发送, 然后回应B请求,完成后,再发送A请求剩下的部分。客户端/服务端发送/接收数据时,会将数据打散乱序发送,接收数据时接收一端再通过streamID标识来将数据合并。

常见的HTTP相应状态码有哪些呢?

200:请求被正常处理
204:请求被受理但没有资源可以返回
206:客户端只是请求资源的一部分,服务器只对请求的部分资源执行GET方法,相应报文中通过Content-Range指定范围的资源。
301:永久性重定向
302:临时重定向
303:与302状态码有相似功能,只是它希望客户端在请求一个URI的时候,能通过GET方法重定向到另一个URI上
304:发送附带条件的请求时,条件不满足时返回,与重定向无关
307:临时重定向,与302类似,只是强制要求使用POST方法
400:请求报文语法有误,服务器无法识别
401:请求需要认证
403:请求的对应资源禁止被访问
404:服务器无法找到对应资源
500:服务器内部错误
503:服务器正忙


image.png

HTTPS

HTTPS经由HTTP进行通信,但利用SSL/TLS来加密数据包。HTTPS 是 HTTP 的安全版,是使用 SSL/TLS 加密的 HTTP 协议。

名词解释

对称加密:两边拥有相同的秘钥,两边都知道如何将密文加密解密。
非对称加密:有公钥私钥之分,公钥所有人都可以知道,可以将数据用公钥加密,但是将数据解密必须使用私钥解密,私钥只有分发公钥的一方才知道。
RSA加密算法:一种非对称加密算法。在公开密钥加密和电子商业中RSA被广泛使用。
RTT(Round-Trip Time):: 往返时延。在计算机网络中它是一个重要的性能指标,表示从发送端发送数据开始,到发送端收到来自接收端的确认(接收端收到数据后便立即发送确认),总共经历的时延。

SSL/TLS

SSL(Secure Socket Layer) 安全套接层
TLS(Transport Layer Security) 传输层安全
TLS 协议位于传输层之上,应用层之下。

1994年,NetScape公司设计了SSL协议(Secure Sockets Layer)的1.0版,但是未发布。
1995年,NetScape公司发布SSL 2.0版,很快发现有严重漏洞。
1996年,SSL 3.0版问世,得到大规模应用。
1999年,互联网标准化组织ISOC接替NetScape公司,发布了SSL的升级版TLS 1.0版。
2006年和2008年,TLS进行了两次升级,分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版

目前,应用最广泛的是TLS 1.0,接下来是SSL 3.0。但是,主流浏览器都已经实现了TLS 1.2的支持。
TLS 1.0通常被标示为SSL 3.1,TLS 1.1为SSL 3.2,TLS 1.2为SSL 3.3。

SSL/TLS协议是为了解决这三大风险而设计的,希望达到:
(1)所有信息都是加密传播,第三方无法窃听。
(2)具有校验机制,一旦被篡改,通信双方会立刻发现。
(3)配备身份证书,防止身份被冒充。

TLS/SSL中使用了非对称加密,对称加密以及HASH算法,一般使用的加密与HASH算法如下:
非对称加密算法:RSA,DSA/DSS
对称加密算法:AES,RC4,3DES
HASH算法:MD5,SHA1,SHA256

通信过程

SSL/TLS协议的基本思路是采用公钥加密法,也就是说,客户端先向服务器端索要公钥,然后用公钥加密信息,服务器收到密文后,用自己的私钥解密。
SSL/TLS协议的基本过程是这样的
(1) 客户端向服务器端索要并验证公钥。
(2) 双方协商生成"对话密钥"。
(3) 双方采用"对话密钥"进行加密通信。
上面过程的前两步,又称为"握手阶段"(handshake)。

详细步骤

一、客户端向服务端发送请求
1)支持的协议版本, eg:TSL1.0
2)支持的加密和压缩算法
3)产生随机数a
二、服务端回应并返回数字证书
1)确定加密协议版本和加密算法,如果浏览器与服务器支持的版本不一致,服务器关闭加密通信。
2)返回证书
3)产生随机数b
三、客户端验证证书
1)客户端用自己的CA公钥去解密证书,如果证书有问题则提示风险
2)生成随机数c(又称"pre-master key"),使用服务端的公钥进行加密,防止被窃听,发送给服务端
3)编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。
4)客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供服务器校验。
四、服务端用三个随机数和算法生成session密钥
1)编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。
2)服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供客户端校验。

之后双方就拿着这个对称加密秘钥来进行正常的通信,接下来完全是使用普通的HTTP协议,只不过用"会话密钥"加密内容。
总结:SSL协议进行了4次通信,在握手阶段使用的是非对称加密,在传输阶段使用的是对称加密。

SSL/TLS协议通信过程
相关问题
如何保证公钥不被篡改?

将公钥放在数字证书中。只要证书是可信的,公钥就是可信的。

公钥加密计算量太大,如何减少耗用的时间?

每一次对话(session),客户端和服务器端都生成一个"对话密钥"(session key),用它来加密信息。由于"对话密钥"是对称加密,所以运算速度非常快,而服务器公钥只用于加密"对话密钥"本身,这样就减少了加密运算的消耗时间。

为什么一定要用三个随机数,来生成"会话密钥"

"不管是客户端还是服务器,都需要随机数,这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的,因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说,pre-master-key本身就是一个随机数,再加上hello消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数,如果随机数不随机,那么pre master secret就有可能被猜出来,那么仅适用pre master secret作为密钥就不合适了,因此必须引入新的随机因素,那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能完全不随机,可是是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的可不是一。"

HTTP 与HTTPS的区别是什么?

  • HTTP 的 URL 以 http:// 开头,而 HTTPS 的URL 以 https:// 开头
  • HTTP 是不安全的,而 HTTPS 是安全的
  • HTTP 标准端口是80,而 HTTPS 的标准端口是443
  • 在OSI 网络模型中,HTTP工作于应用层,而HTTPS 的安全传输机制工作在传输层
  • HTTP 无法加密,而HTTPS 对传输的数据进行加密
  • HTTP无需证书,而HTTPS 需要CA机构wosign的颁发的SSL证书

一篇文章彻底了解HTTP发展史
常见的HTTP状态码(HTTP Status Code)
HTTP的长连接和短连接
TCP连接复用
杂谈:HTTP1.1 与 HTTP2.0 知多少?
SSL/TLS协议运行机制的概述
HTTP常见面试题

WebSocket

HTTP 协议通信只能由客户端发起,很多网站为了实现推送技术,所用的技术都是轮询。轮询是在特定的的时间间隔(如每秒),由浏览器对服务器发出HTTP请求,然后由服务器返回最新的数据给客户端的浏览器。这种传统的模式带来很明显的缺点,即浏览器需要不断的向服务器发出请求,然而HTTP请求可能包含较长的头部,其中真正有效的数据可能只是很小的一部分,显然这样会消耗很多的带宽资源。

WebSocket 协议在2008年诞生,2011年成为国际标准。所有浏览器都已经支持了。
它的最大特点就是,服务器可以主动向客户端推送信息,客户端也可以主动向服务器发送信息,是真正的双向平等对话,属于服务器推送技术的一种。

  • WebSocket 是独立的、创建在 TCP协议之上,服务器端的实现比较容易。
  • 与 HTTP 协议有着良好的兼容性。默认情况下,Websocket协议使用80端口;运行在TLS之上时,默认使用443端口。握手阶段采用 HTTP 协议,因此握手时不容易屏蔽,能通过各种 HTTP 代理服务器。
  • 数据格式比较轻量,性能开销小,通信高效。
  • 可以发送文本,也可以发送二进制数据。
  • 没有同源限制,客户端可以与任意服务器通信。
  • 协议标识符是ws(如果加密,则为wss),服务器网址就是 URL。
  • Websocket 通过HTTP/1.1 协议的101状态码进行握手。
  • 为了创建Websocket连接,需要通过浏览器发出请求,之后服务器进行回应,这个过程通常称为“握手”(handshaking)。
优点
  • 较少的控制开销。(数据包头部)
  • 更强的实时性。
  • 保持连接状态。
  • 更好的二进制支持。
  • 可以支持扩展。
  • 更好的压缩效果。

WebSocket 教程

DNS

什么是 DNS

DNS(Domain Name System,域名系统),是互联网上作为域名和IP地址相互映射的一个分布式数据库。DNS 服务用于在网络请求时,将域名转为 IP 地址。能够使用户更方便的访问互联网,而不用去记住能够被机器直接读取的 IP 数串。
传统的基于 UDP 协议的公共 DNS 服务极易发生 DNS 劫持,从而造成安全问题。

DNS解析过程

1.浏览器中输入 www.linkedkeeper.com,发出解析请求。
2.本机的域名解析器 resolver 程序查询本地缓存和 host 文件中是否为域名的映射关系,如果有则调用这个 IP 地址映射,完成解析。
3.如果 hosts 与本地解析器缓存都没有相应的网址映射关系,则本地解析器会向 TCP/IP 参数中设置的首选 DNS 服务器(我们叫它 Local DNS 服务器)发起一个递归的查询请求。
4.服务器收到查询时,如果要查询的域名由本机负责解析,则返回解析结果给客户机,完成域名解析,此解析具有权威性。如果要查询的域名,不由 Local DNS 服务器解析,但该服务器已缓存了此网址映射关系,则调用这个 IP 地址映射,完成域名解析,此解析不具有权威性。
5.如果 Local DNS 服务器本地区域文件与缓存解析都失效,则根据 Local DNS 服务器的设置(是否递归)进行查询,如果未用开启模式,Local DNS 就把请求发至13台 Root DNS。如果用的是递归模式,此 DNS 服务器就会把请求转发至上一级 DNS 服务器,由上一级服务器进行解析,上一级服务器如果不能解析,或找根 DNS 或把转请求转至上上级,以此循环。
6.Root DNS 服务器收到请求后会判断这个域名是谁来授权管理,并会返回一个负责该顶级域名服务器的一个 IP。
7.Local DNS 服务器收到 IP 信息后,将会联系负责 .com 域的这台服务器。
8.负责 .com 域的服务器收到请求后,如果自己无法解析,它就会找一个管理 .com 域的下一级 DNS 服务器地址给本地 DNS 服务器。
9.当 Local DNS 服务器收到这个地址后,就会找 linkedkeeper.com 域服务器,10、11重复上面的动作,进行查询。
10.最后 www.linkedkeeper.com 返回需要解析的域名的 IP 地址给 Local DNS 服务器。
11.Local DNS 服务器缓存这个解析结果(同时也会缓存,6、8、10返回的结果)。
12.Local DNS 服务器同时将结果返回给本机域名解析器。
13.本机缓存解析结果。
14.本机解析器将结果返回给浏览器。
15.浏览器通过返回的 IP 地址发起请求。

递归查询和迭代查询

递归查询:如果主机所询问的本地域名服务器不知道被查询域名的 IP 地址,那么本地域名服务器就以 DNS 客户的身份,向其他根域名服务器继续发出查询请求报文,而不是让该主机自己进行下一步的查询。
迭代查询:当根域名服务器收到本地域名服务器发出的迭代查询请求报文时,要么给出所要查询的 IP 地址,要么告诉本地域名服务器:你下一步应当向哪一个域名服务器进行查询。然后让本地域名服务器进行后续的查询,而不是替本地域名服务器进行后续的查询。

由此可见,客户端到 Local DNS 服务器,Local DNS 与上级 DNS 服务器之间属于递归查询;DNS 服务器与根 DNS 服务器之前属于迭代查询。
实际环境中,因为采用递归模式会导致 DNS 服务器流量很大,所以现在大多数的 DNS 都是迭代模式。

域名劫持的几种方法

1.假扮域名注册人和域名注册商通信;
2.伪造域名注册人在注册商处的账户信息;
3.伪造域名注册人的域名转移请求;
4.直接进行一次域名转移请求;
5.修改域名的DNS记录。

HttpDNS 是什么

HttpDNS 利用 HTTP 协议与 DNS 服务器交互,代替了传统的基于 UDP 协议的 DNS 交互,绕开了运营商的 Local DNS,有效防止了域名劫持,提高域名解析效率。另外,由于 DNS 服务器端获取的是真实客户端 IP 而非 Local DNS 的 IP,能够精确定位客户端地理位置、运营商信息,从而有效改进调度精确性。

HttpDNS 主要解决的问题
  • Local DNS 劫持:由于 HttpDns 是通过 IP 直接请求 HTTP 获取服务器 A 记录地址,不存在向本地运营商询问 domain 解析过程,所以从根本避免了劫持问题。
  • 平均访问延迟下降:由于是 IP 直接访问省掉了一次 domain 解析过程,通过智能算法排序后找到最快节点进行访问。
  • 用户连接失败率下降:通过算法降低以往失败率过高的服务器排序,通过时间近期访问过的数据提高服务器排序,通过历史访问成功记录提高服务器排序。

目前,国内有一部分厂商已经提供了这个解析服务,可以直接使用第三方服务。直接发一个 Get 请求,带上请求参数,返回结果以 json 返回。

http://xxxxxx?host=www.linkedkeeper.com

请求成功时,返回结果如下:

{
  "host": "www.linkedkeeper.com",
  "ips": [
    "115.238.23.241",
    "115.238.23.251"
  ],
  "ttl": 57
}

在移动端,将由 HttpDns 获得的 IP 地址在原有 URL 的基础上,将域名替换为 IP,然后用新的 URL 发起 HTTP 请求。

HttpDns 原理是什么
域名劫持的几种方法
DNS域名劫持的几种方式及解决方法

互联网协议入门

ISO/OSI七层网络参考模型:应用层、表示层、会话层、运输层、网络层、数据链路层和物理层。
/IP四层网络模型:应用层、运输层、网络层和网络接口层。
五层网络模型:应用层、运输层、网络层、数据链路层和物理层。
如何分层有不同的模型,有的模型分七层,有的分四层。只需要知道,互联网分成若干层就可以了。
互联网的每一层,都定义了很多协议。这些协议的总称,就叫做"互联网协议"(Internet Protocol Suite)。它们是互联网的核心,下面介绍每一层的功能,主要就是介绍每一层的主要协议。

网络模型

image.png

实体层 / 物理层

它就是把电脑连接起来的物理手段。它主要规定了网络的一些电气特性,作用是负责传送0和1的电信号。

链接层 / 数据链路层

"链接层"的功能,它在"实体层"的上方,确定了0和1的分组方式。
早期的时候,每家公司都有自己的电信号分组方式。逐渐地,一种叫做"以太网"(Ethernet)的协议,占据了主导地位。以太网规定,一组电信号构成一个数据包,叫做"帧"(Frame)。每一帧分成两个部分:标头(Head)和数据(Data)。

  • "标头"包含数据包的一些说明项,比如发送者、接受者、数据类型等等;"数据"则是数据包的具体内容。
  • "标头"的长度,固定为18字节。"数据"的长度,最短为46字节,最长为1500字节。如果数据很长,就必须分割成多个帧进行发送。
  • 以太网规定,连入网络的所有设备,都必须具有"网卡"接口。数据包必须是从一块网卡,传送到另一块网卡。网卡的地址,就是数据包的发送地址和接收地址,这叫做MAC地址。每块网卡出厂的时候,都有一个全世界独一无二的MAC地址,长度是48个二进制位,通常用12个十六进制数表示。前6个十六进制数是厂商编号,后6个是该厂商的网卡流水号。eg:00-B0-D0-86-BB-F7
  • 1号计算机向2号计算机发送一个数据包,同一个子网络的3号、4号、5号计算机都会收到这个包。它们读取这个包的"标头",找到接收方的MAC地址,然后与自身的MAC地址相比较,如果两者相同,就接受这个包,做进一步处理,否则就丢弃这个包。这种发送方式就叫做"广播"(broadcasting)。
image.png

网络层

  • 如果两台计算机不在同一个子网络,广播是传不过去的。
  • 如果是同一个子网络,就采用广播方式发送,否则就采用"路由"方式发送。
  • 这就导致了"网络层"的诞生。它的作用是引进一套新的地址,使得我们能够区分不同的计算机是否属于同一个子网络。这套地址就叫做"网络地址",简称"网址"。
IP协议
  • 规定网络地址的协议,叫做IP协议。它所定义的地址,就被称为IP地址。目前,广泛采用的是IP协议第四版,简称IPv4。这个版本规定,网络地址由32个二进制位组成。习惯上,我们用分成四段的十进制数表示IP地址,从0.0.0.0一直到255.255.255.255。
  • 互联网上的每一台计算机,都会分配到一个IP地址。这个地址分成两个部分,前一部分代表网络,后一部分代表主机。
  • 通过"子网掩码"判断两台计算机是否属于同一个子网络。
  • 总结一下,IP协议的作用主要有两个,一个是为每一台计算机分配IP地址,另一个是确定哪些地址在同一个子网络
IP数据包
  • 把IP数据包直接放进以太网数据包的"数据"部分,因此完全不用修改以太网的规格。这就是互联网分层结构的好处:上层的变动完全不涉及下层的结构。
  • IP数据包的"标头"部分的长度为20到60字节,整个数据包的总长度最大为65,535字节。因此,理论上,一个IP数据包的"数据"部分,最长为65,515字节。前面说过,以太网数据包的"数据"部分,最长只有1500字节。因此,如果IP数据包超过了1500字节,它就需要分割成几个以太网数据包,分开发送了。


    image.png
ARP协议

传输层

  • 当一个数据包从互联网上发来的时候,怎么知道,它是表示网页的内容,还是表示在线聊天的内容?我们需要一个参数,表示这个数据包到底供哪个程序(进程)使用。这个参数就叫做"端口"(port),它其实是每一个使用网卡的程序的编号。每个数据包都发到主机的特定端口,所以不同的程序就能取到自己所需要的数据。
  • "端口"是0到65535之间的一个整数,正好16个二进制位。0到1023的端口被系统占用,用户只能选用大于1023的端口。不管是浏览网页还是在线聊天,应用程序会随机选用一个端口,然后与服务器的相应端口联系。
  • "传输层"的功能,就是建立"端口到端口"的通信。相比之下,"网络层"的功能是建立"主机到主机"的通信。只要确定主机和端口,我们就能实现程序之间的交流。
UDP协议
  • UDP数据包,也是由"标头"和"数据"两部分组成。
  • "标头"部分主要定义了发出端口和接收端口,"数据"部分就是具体的内容。
  • UDP数据包非常简单,"标头"部分一共只有8个字节,总长度不超过65,535字节,正好放进一个IP数据包。
  • UDP协议的优点是比较简单,容易实现,但是缺点是可靠性较差,一旦数据包发出,无法知道对方是否收到。
image.png
TCP协议
  • 它就是有确认机制的UDP协议,每发出一个数据包都要求确认。如果有一个数据包遗失,就收不到确认,发出方就知道有必要重发这个数据包了。
  • TCP协议能够确保数据不会遗失。它的缺点是过程复杂、实现困难、消耗较多的资源。
  • TCP数据包没有长度限制,理论上可以无限长,但是为了保证网络的效率,通常TCP数据包的长度不会超过IP数据包的长度,以确保单个TCP数据包不必再分割。

应用层

  • "应用层"的作用,就是规定应用程序的数据格式。
  • TCP协议可以为各种各样的程序传递数据,比如Email、WWW、FTP等等。那么,必须有不同协议规定电子邮件、网页、FTP数据的格式,这些应用程序协议就构成了"应用层"。
  • 这是最高的一层,直接面对用户。它的数据就放在TCP数据包的"数据"部分。
image.png

用户的上网设置

  • 计算机每次开机,都会分到同样的IP地址,所以这种情况被称作"静态IP地址上网"。
  • 所谓"动态IP地址",指计算机开机后,会自动分配到一个IP地址,不用人为设定。它使用的协议叫做DHCP协议。
  • 这个协议规定,每一个子网络中,有一台计算机负责管理本网络的所有IP地址,它叫做"DHCP服务器"。新的计算机加入网络,必须向"DHCP服务器"发送一个"DHCP请求"数据包,申请IP地址和相关的网络参数。
  • DNS协议将网址转换成IP地址。已知DNS服务器为8.8.8.8,于是我们向这个地址发送一个DNS数据包(53端口)。然后,DNS服务器做出响应,告诉我们Google的IP地址是172.194.72.105。于是,我们知道了对方的IP地址。
image.png

image.png

互联网协议入门
关于 TCP/IP,必知必会的10个问题

推荐文章:
HTTP缓存机制 & cookie/localStorage/sessionStorage
前端开发之走进Vue.js(入门知识点)
《你不知道的javascript上卷》摘要(上)
《你不知道的javascript上卷》摘要(下)
Git使用总结
如何在Vue+Webpack下配置Stylelint
Highchart属性笔记

原文:前端须知的网络知识(TCP/UDP/HTTP/HTTPS...)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,829评论 1 331
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,603评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,846评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,600评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,780评论 3 272
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,695评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,136评论 2 293
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,862评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,453评论 0 229
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,942评论 2 233
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,347评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,790评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,293评论 3 221
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,839评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,448评论 0 181
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,564评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,623评论 2 249