浏览器中常见网络协议介绍

标签: 浏览器 常见 网络协议 | 发表时间:2015-06-03 11:35 | 作者:
出处:https://www.imququ.com

本周五我在公司有一个关于《HTTP 协议》的培训,只有两个小时,估计能讲到的东西不会太多。实际上,浏览器为了完成 WEB 应用的各项功能,需要跟各种网络协议打交道,HTTP 只是其中一种。本文会介绍浏览器中常见的网络协议,以及各种协议之间的关系。

我们经常会听到「TCP/IP 协议」这个名词,从字面上来看,有人会认为它专指 TCP 和 IP 两种协议。实际上大多数情况,TCP/IP 协议指的是整个网际协议族(Internet Protocol Suite),是利用 IP 协议进行通讯的其他协议统称。TCP/IP 包含的协议众多,还有一个分层模型。相比较 OSI 模型,TCP/IP 的分层更简单,从下到上分别为:物理层、数据链路层、网络层、传输层和应用层。

IP(Internet Protocol)属于网络层协议,负责联网主机之间的路由选择和寻址。IPv4 中的 4 指的是 TCP/IP 协议的第 4 个版本,直到这个版本,IP 协议才单独拆出来,所以并没有单独的 IPv1 - IPv3。而 IPv5 分给了一个没什么进展的试验性协议,所以下一个版本的 IP 协议变成了 IPv6。

TCP(Transmission Control Protocol)和 UDP(User Datagram Protocol)是整个 TCP/IP 协议中最重要的两个传输层协议。TCP 是面向连接的、可靠的流协议;UDP 是不具有可靠性的数据报协议。后面可以看到,对可靠性要求比较高的上层协议一般会基于 TCP;而对高速传输和实时性有较高要求的上层协议一般会基于 UDP。

介绍完比较低层的 IP、TCP 和 UDP 之后,下面看几个浏览器中常见的应用层协议。

HTTP 与 WebSocket

HTTP 协议是浏览器需要用到的最重要的网络协议,它包括很多版本,例如最常见的 HTTP/1.1,刚刚发布的 HTTP/2,还有 Google 实现的过渡版本 SPDY 等等。本文不讨论 HTTP 的细节以及各版本之间的差异,只打算列出 HTTP 与其他协议 / 应用之间的关系,见下图:

  +-------------+-------------+--------------+
|     XHR     |     SSE     |      WS      |
+-------------+-------------+------+       +
|               HTTP               |       |
+----------------------------------+-------+
|                    TLS *                 |
+------------------------------------------+
|                    TCP                   |
+------------------------------------------+
|                    IP                    |
+------------------------------------------+

从上图可以看出 HTTP 是在 TCP 之上实现的,所以 HTTP 中并不需要关注数据传输的可靠性,类似于顺序控制、重发这样的机制在传输层已经有了。同时,HTTP 也拥有 TCP 的一些缺点,给 WEB 性能优化带来挑战。

XHR( XmlHTTPRequest)和 SSE( Server-Sent Events)都是浏览器提供的数据交互功能,它们的本质都还是 HTTP。XHR 是 Ajax 技术的核心,大家都很熟,从略;SSE 概念还算新,这里多说几句。我们知道 HTTP 只能由客户端发起请求,再由服务端响应。SSE 也是这样,只不过服务端会利用这个 HTTP 连接多次发送响应,不像平时发送完响应就结束了。实际上,很早之前在 WebIM 中类似的 HTTP 长连接技术就已经很盛行了,有兴趣的同学可以看下这篇八年前的文章: Comet:基于 HTTP 长连接的「服务器推」技术

既然 XHR 和 SSE 本质都是 HTTP 连接,所以 HTTP 协议中一些常见概念,例如请求方式(GET、POST 等),请求响应头部(Cookie、内容编码、传输编码、缓存等)等等,依然存在。

而 WS(WebSocket)是直接基于 TCP 实现的,HTTP 协议中的那些概念都不复存在。需要注意的是,从前面图表中可以看出,它还是依赖于 HTTP,这是因为 WebSocket 握手利用了 HTTP 的 Upgrade 机制。一旦握手完成,后续数据传输就直接在 TCP 上完成。浏览器中新协议借助 HTTP 作为引导,是一个较为普遍的做法。

TLS(Transport Layer Security,传输层安全),作用是保证数据在传输过程中的完整性和保密性,属于可选项。启用了 TLS 之后,HTTP 协议的 URL 前缀需要由 http:// 改成 https://;WebSocket 协议的 URL 前缀需要由 ws:// 改成 wss://

DNS

DNS(Domain Name System),就是大家熟知的域名解析服务,提供了从域名到 IP 的转换。浏览器中大部分网络交互都会使用域名,而传输层协议需要的是 IP,所以 DNS 是基础。

  +-------------------------------+
|              DNS              |
+-------------------------------+
|      TCP      |      UDP      |
+---------------+---------------+
|               IP              |
+-------------------------------+

DNS 服务默认使用 UDP 协议获得查询结果,通常仅当结果超过 512 字节或者进行 DNS 服务器同步时才会使用 TCP 协议。这是因为 DNS 的使用非常频繁,又是基础,响应速度是优先需要考虑的。使用 UDP 可以满足速度上的要求,但同时也引入了类似于「DNS 缓存投毒」这类问题。

WebRTC

WebRTC(Web Real-Time Communication)出现之前,DNS 几乎是浏览器唯一使用的基于 UDP 的协议。WebRTC 提供的三大功能中,MediaStream 与网络无关,RTCPeerConnection 和 RTCDataChannel 都是基于 UDP,如图:

  +-----------------------+-------------------------+
|   RTCPeerConnection   |      RTCDataChannel     |
+-----------------------+-------------------------+
|          SRTP         |           SCTP          |
+             +---------+-------------------------+
|             |                DTLS               |
+-------------+-----------------------------------+
|                ICE, STUN, TURN                  |
+-------------------------------------------------+
|                       UDP                       |
+-------------------------------------------------+
|                       IP                        |
+-------------------------------------------------+

这个图比较复杂,我们从下往上介绍:

ICE(Interactive Connectivity Establishment)框架,作用是在端与端之间建立一条有效的通道,优先直连,其次用 STUN 协商,再不行只能用 TURN 转发:

  • STUN(Session Traversal Utilities for NAT)协议,解决了三个问题:1)获得外网 IP 和端口;2)在 NAT 中建立路由条目,绑定外网端口,使得到达外网 IP 和端口的入站分组能找到应用程序,不被丢弃;3)定义了一个简单的 keep-alive 机制,保证 NAT 路由条目不会因为超时而被删除。STUN 服务器必须架设在公网上,可以自己搭建,也可以使用第三方提供的公开服务,例如 Google 的「stun:stun.l.google.com:19302」。
  • TURN(Traversal Using Relays around NAT)协议,依赖外网中继设备在两端之间传递数据。简单说就是通过两端都可以访问的 TURN 服务转发消息,间接把两端连起来。

DTLS(Datagram Transport Layer Security,数据报传输层安全),本质上就是 TLS,只是为了兼容 UDP 的数据报传输而做了一些微小的修改,可以简单把它理解为 UDP 版的 TLS。

再往上就兵分两路,一路的目标是 RTCPeerConnection,负责音频和视频数据通信,对传输速度和实时性有很高的要求,这里又有两个新的协议出现:

  • SRTP(Secure Real-time Transport Protocol,安全实时传输协议)。WebRTC 中的音频和视频等实时数据都是通过这个协议传输。它是 RTP 协议的安全版。
  • SRTCP(Secure Real-Time Control Transport Protocol,安全实时控制传输协议)。它会跟踪 SRTP 的运行情况,以便调整每个流的发送速率、编码品质和其他参数。它是 RTCP 协议的安全版。

另一路的目标是 RTCDataChannel,用来在端到端之间传输任意应用数据,SRTP 是专门为传输媒体数据为设计的,不适合传输应用数据,所以这里又需要一个新的协议:

  • SCTP(Stream Control Transmission Protocol,流控制传输协议)。本身 SCTP 是一个传输层协议,直接运行在 IP 协议之上,与 TCP 和 UDP 类似。但在 WebRTC 这里,SCTP 却运行于 DTLS 之上。SCTP 很好的一点是提供了交付属性选项,使用者可以指定消息是有序还是乱序,是可靠还是部分可靠,部分可靠时还可以指定使用超时重传还是计数重传策略。

QUIC

Google 正在试验一种新的传输层协议:QUIC(Quick UDP Internet Connections),它的本质是基于 UDP 实现 HTTP,相当于之前的 TCP + TLS。从目前的资料来看,QUIC 可以大幅减少建立连接的时间,这是通过简化握手步骤从而减少 RTT(Round-Trip Time)来实现的,类似于 TFO(TCP Fast Open)。有兴趣的同学可以点 这个连接围观,据说 Google 自家服务来自 Chrome 的请求中,已经有 50% 使用了 QUIC 协议。

最后表达下对 Google 的佩服。为了优化 WEB 性能,在浏览器(Chrome)、排版引擎(Blink)、JS 引擎(V8)、图片格式(WebP)、传输层协议(TCP 的 TFO,QUIC)、应用层协议(SPDY)以及 HTML5(从 Google Gears 开始)等等方面都做了大量努力,实在是技术型公司典范,叹为观止!

本文链接: https://www.imququ.com/post/network-protocol-in-browser.html参与讨论

推荐: 领略前端技术 阅读奇舞周刊

相关 [浏览器 常见 网络协议] 推荐:

浏览器中常见网络协议介绍

- - JerryQu 的小站
本周五我在公司有一个关于《HTTP 协议》的培训,只有两个小时,估计能讲到的东西不会太多. 实际上,浏览器为了完成 WEB 应用的各项功能,需要跟各种网络协议打交道,HTTP 只是其中一种. 本文会介绍浏览器中常见的网络协议,以及各种协议之间的关系. 我们经常会听到「TCP/IP 协议」这个名词,从字面上来看,有人会认为它专指 TCP 和 IP 两种协议.

常见浏览器内核

- - Web前端 - ITeye博客
一、Trident内核代表产品Internet Explorer,又称其为IE内核. Trident(又称为MSHTML),是微软开发的一种排版引擎. 使用Trident渲染引擎的浏览器包括:IE、傲游、世界之窗浏览器、Avant、腾讯TT、Netscape 8、NetCaptor、Sleipnir、GOSURF、GreenBrowser和KKman等.

常见浏览器兼容性问题与解决方案

- - 浏览器 - 互联网 - ITeye博客
浏览器兼容问题一:不同浏览器的标签默认的外补丁和内补丁不同. 问题症状:随便写几个标签,不加样式控制的情况下,各自的margin 和padding差异较大. 解决方案:CSS里 *{margin:0;padding:0;}. 备注:这个是最常见的也是最易解决的一个浏览器兼容性问题,几乎所有的CSS文件开头都会用通配符*来设置各个标签的内外补丁是0.

dropwatch 网络协议栈丢包检查利器

- - 系统技术非业余研究
原创文章,转载请注明: 转载自 系统技术非业余研究. dropwatch 网络协议栈丢包检查利器. 在做网络服务器的时候,会碰到各种各样的网络问题比如说网络超时,通常一般的开发人员对于这种问题最常用的工具当然是tcpdump或者更先进的wireshark来进行抓包分析. 通常这个工具能解决大部分的问题,但是比如说wireshark发现丢包,那深层次的原因就很难解释了.

Silk 浏览器:Google? No!

- 橙子 - 爱范儿 · Beats of Bits
前苹果员工, Blogger Chris Espinosa 指出, Amazon 的 Silk 浏览器技术,让 Amazon 不能把自己置于 Google 的控制之下. Silk 在云端为用户组织和优化网页,之后再下载到本地. 这样做的结果是, Amazon 能掌握用户在网络上的一举一动. 不仅仅包括在 Amazon.com 下的订单.

浏览器检测

- - JavaScript - Web前端 - ITeye博客
1.navigator 对象. 由于每个浏览器都具有自己独到的扩展, 所以在开发阶段来判断浏览器是一个非常重要的步骤. 虽然浏览器开发商在公共接口方面投入了很多精力, 努力的去支持最常用的公共功能;但在现实中,浏览器之间的差异,以及不同浏览器的“怪癖”却是非常多的,因此客户端检测除了是一种补救措施,更是一种行之有效的开发策略.

新的无线网络协议支持高准确度的位置定位

- - 动点科技
这篇客座专栏由Ciaran Connell撰写,他是 . DecaWave 的首席执行官——提供802.15.4a标准的芯片,支持物联网和实时定位系统. 这几天,室内定位这个概念很火爆. 苹果发布了iBeacon,在店内和商场内添加位置信息. 谷歌正在频繁发布谷歌室内地图的新场馆,有数十家创业公司正在发布在商场,医院,机场和办公室内部的解决方案,遍及全球.

浏览器缓存机制

- Leo Pay - Learning Correcting Improving
Cache-Control 是最重要的规则. 这个字段用于指定所有缓存机制在整个请求/响应链中必须服从的指令. 这些指令指定用于阻止缓存对请求或响应造成不利干扰的行为. 缓存指令是单向的,即请求中存在一个指令并不意味着响应中将存在同一个指令. cache-control 定义是:Cache-Control = "Cache-Control" ":" cache-directive.

浏览器进化史

- Hao Zeng - 爱范儿 · Beats of Bits
这张图非常直观,纵轴是浏览器存在的时间线,横轴代表使用此浏览器的用户数量. 出现在图片中的浏览器包括:Netscape、Opera、IE、Firefox、Safari 和 Chrome. Netscape:1994 年诞生,1995 年用户基数达到最大(2.x 版本). 1998 年 Netscape 被创业杀手 AOL 收购,再加上微软的冲击,逐渐走向衰败,2008 年彻底终结.

百度浏览器评测

- 溪梦 - 月光博客
  百度今年在客户端方面的动作不断,目前已经推出了百度输入法、百度电脑管家、百度安全卫士、百度影音,百度压缩软件,而现在,百度客户端领域的重要产品百度浏览器已经进入了测试阶段,不久后将正式对外发布.   百度在其公关稿里称:“百度浏览器具备以下几点特性:第一,整合百度平台的热门应用,使用户一键触达;第二,采用沙箱安全技术将用户电脑与病毒木马隔离;第三,融合百度搜索技术的智能地址栏;第四,界面设计简洁易操作……百度希望通过浏览器的改进,推动互联网的良性发展,吸引更多的用户来使用互联网,增进使用的频度与时长,最终推动搜索这个媒体平台的发展和巩固.