网络传输协议

前言 在当今数字化世界中，网络通信和存储技术始终是不可或缺的因素，特地是在云计算、边缘计算和物联网等畛域。传统的内核级别协定和框架在某些场景下曾经显得不够灵便和高效。为了满足更高的性能、更低的提早和更大的可扩展性需要，用户级别的协定和框架开始锋芒毕露。本文将介绍三个重要的用户级协定和框架：DPDK（Data Plane Development Kit）、SPDK（Storage Performance Development Kit）和VPP（Vector Packet Processing），并探讨它们实用的业务场景、劣势以及它们所带来的晋升，同时也会探讨这些用户级协定和框架在将来的发展趋势。 DPDK（Data Plane Development Kit）：高性能数据包解决 定义： DPDK是一款用于高性能数据包解决的开源软件库和工具集，专一于用户级协定栈。它的设计指标是提供在网络性能虚拟化（NFV）、云计算、边缘计算等畛域中实现高吞吐量和低提早的网络应用所需的性能和可伸缩性。 背景： 随着网络应用的一直倒退和遍及，对高性能网络数据包解决的需要一直减少。传统的操作系统内核网络栈在解决大量数据包时可能引入较高的提早和资源开销。DPDK应运而生，通过绕过操作系统内核，间接拜访硬件资源，提供了卓越的性能。其核心思想是采纳轮询模式，打消了操作系统内核中的上下文切换和锁竞争，从而显著缩小了数据包解决的提早。 利用场景： DPDK的典型利用场景包含但不限于： 虚构路由器（Virtual Routers）： 通过DPDK，能够实现高性能的虚构路由器，提供疾速的数据包路由和转发性能，实用于数据中心和云环境中的虚拟化网络。防火墙（Firewalls）： DPDK可用于构建高吞吐量的防火墙利用，实现对网络流量的深度包检查和过滤。负载均衡器（Load Balancers）： 在负载均衡器中应用DPDK能够实现疾速的流量散发和申请解决，确保服务的高可用性和性能。网络包分析器（Network Packet Analyzers）： DPDK提供了解决网络流量的能力，可用于构建网络包剖析工具，帮忙监控和故障排除网络。劣势： 应用DPDK带来以下要害劣势： 高性能： DPDK的设计和实现使其可能达到卓越的数据包解决性能，提供更高的吞吐量和更低的提早。硬件形象： DPDK提供了硬件形象层，使开发人员可能编写与特定硬件无关的应用程序，简化了在不同硬件平台上的移植工作。用户级协定栈： DPDK容许开发人员在用户空间中实现网络协议栈，绕过操作系统内核，缩小了零碎调用和内核模式切换的开销。可伸缩性： DPDK的架构反对多核解决，容许应用程序充分利用多核处理器，实现更好的可伸缩性。SPDK（Storage Performance Development Kit）：高性能存储减速 定义： SPDK是一个旨在提供高性能存储应用程序的用户级协定栈和工具集，专一于存储性能减速。它为解决高速存储设备，如NVMe SSD（Non-Volatile Memory Express Solid-State Drives），提供了弱小的性能和性能。通过将存储用的驱动转移到用户态，防止零碎调用带来的性能损耗，顺便做到间接通过用户态落盘从而实现零拷贝。另外应用polling模式防止旧的中断计划产生的不稳定性能和延时损耗。 背景： 随着数据量的爆炸性增长和存储设备性能的一直晋升，存储应用程序对高性能存储解决方案的需要也在一直减少。传统的操作系统内核存储栈在解决高速存储设备时可能成为性能瓶颈，导致高I/O提早和无限的吞吐量。SPDK的设计指标是通过绕过操作系统内核，间接与存储硬件通信，来克服这些性能限度。 利用场景： SPDK的典型利用场景包含但不限于： 云存储（Cloud Storage）： 在云环境中，SPDK能够减速分布式存储系统，提供高吞吐量和低提早的数据存储和检索。数据库（Databases）： 数据库应用程序能够通过SPDK取得更快的I/O性能，减速数据读写操作，进步数据库响应速度。分布式文件系统（Distributed File Systems）： SPDK能够用于构建高性能的分布式文件系统，反对大规模数据存储和散发。劣势： 应用SPDK带来以下要害劣势： 性能晋升： SPDK通过绕过操作系统内核，实现了存储硬件的间接拜访，从而大幅晋升了I/O性能，升高了提早。硬件形象： SPDK提供了硬件形象层，使开发人员可能编写与特定存储设备和协定无关的应用程序，简化了跨不同硬件平台的移植工作。丰盛的模块和驱动程序： SPDK反对多种存储协定（如NVMe、iSCSI等）和存储设备类型，提供了丰盛的模块和驱动程序，满足不同利用的需要。易于应用的API： SPDK提供了用户敌对的API和工具，使开发人员可能更轻松地构建、测试和部署高性能存储应用程序。VPP（Vector Packet Processing）：高性能网络数据立体 定义： VPP是一款面向高性能网络数据立体的框架，旨在为网络性能虚拟化（NFV）、SD-WAN、边缘路由器等利用场景提供弱小的网络数据处理能力。 背景： 随着网络流量的快速增长和网络应用的多样化，对高性能网络数据立体的需要变得愈发重要。传统的网络数据立体往往受限于性能瓶颈和可伸缩性问题。VPP的设计指标是通过采纳面向包的数据模型和高度优化的数据包解决引擎来应答这些挑战，提供卓越的数据包解决性能。 ...

流的定义流是一系列通过网络中某一观察点的具备雷同属性的数据包，属性包含 端点：流的终点和起点方向：单向或双向工夫粒度：数据包的发送起始工夫和终止工夫协定档次：包含网络各层协定NetFlow/IPFIX协定介绍与关系Netflow: 于1996年由思科公司创造，于同年5月注册为美国专利。首先用于网络设备对数据交换进行减速，并同步实现对高速转发的IP数据流进行测量和统计，通过多年的技术演进，NetFlow原来用于数据交换减速的性能曾经逐渐由网络设备中的专用ASIC 芯片实现，而对IP数据流进行测量和统计的性能也已更加成熟，造成了一种专用流替换技术，NetFlow已集成到大多数厂商的路由器和交换机内成为流量监测的事实标准，广泛应用于网络管理IPFIX：全称IP Flow Information Export，即IP流信息输入，在 2003 年，Netflow V9 被 IETF 组织从 5 个候选计划中确定为 IPFIX规范，作为IP网络中的流信息测量的标准协议，是网络流量监测的国际标准，是一种针对数据流特征分析、基于模板的格局输入的协定，因而具备很强的可扩展性协定毛病netflow: 耗费路由器的CPU和存储资源，对设施的转发性能有影响流记录的数据量依然很大，非独立设施，解决能力有余，因而，个别采纳100～1000:1采样比，监测粒度较粗，损失流量的细节信息设施自身提供的数据内容有局限性，策略和定制能力绝对较差。NetFlow性能集成在设施内，软件实现性能差、硬件实现灵活性差，对于大量已部署运行的路由器降级板卡费用高NetFlow业务和利用辨认次要依赖于TCP/UDP端口号，无奈辨认突飞猛进的业务协定零碎组成Exporter/探测器：用于监听网络数据Collector/采集器：用于收集从 Exporter 输入的网络数据Analysis/剖析报告零碎：用于剖析从 Collector 收集到的网络数据，并产生报告netflow数据字段数据流 源IP目标IP协定端口流量统计数据 数据流时戳源 IP 地址目标 IP 地址源端口号目标端口号输出接口号和输入接口号下一跳 IP 地址信息流中的总字节数信息流中的数据包数量信息流中的第一个和最初一个数据包时戳 源 AS 和目标 AS前置掩码数据包序号IPFIX数据字段为了较完整的输入数据，IPFIX 缺省应用网络设备的七个要害域来示意每股网络流量，如果不同的 IP 报文中所有的七个要害域都匹配，那么这些 IP 报文都将被视为属于同一股流量 通过记录网络中这些流量的特色，如流量持续时间、流量中报文均匀长度等， 咱们能够理解到以后网络的利用状况，并依据这些信息对网络进行优化，平安检测，流量计费 源 IP 地址目标IP 地址TCP/UDP 源端口TCP/UDP 目标端口三层协定类型服务类型Type-of-service字节输出逻辑接口协定收集器collector依赖开源我的项目goflow2(golang我的项目) https://github.com/netsampler/goflow2构建 $ git clone https://github.com/netsampler/goflow2.git$ cd goflow2$ make build会产生一个dist文件夹，外面蕴含一个可执行文件dist/goflow2-版本-git-commit-架构 把可执行文件重命名为goflow2 执行监听，能够看到该程序同时反对netflow/sflow协定采集，监听udp2055端口收集netflow协定数据包，放弃这个终端不敞开，接下去开始执行协定探测程序 $ ./dist/goflow2 INFO[0000] starting GoFlow2 INFO[0000] starting collection count=1 hostname= port=6343 scheme=sflowINFO[0000] starting collection count=1 hostname= port=2055 scheme=netflow协定探测exporter依赖开源我的项目softflowd（c语言我的项目）作为流量探测器，能够探测linux主机物理网口的网卡流量信息，并且依照netflow/ipfix协定定义封装流量包发送到指定的采集器 ...

本文为「Dev for Dev 专栏」系列内容，作者为声网大后端传输协定负责人 夏天。针对实时互动利用对网络传输带来的新需要和新挑战，声网通过将实时互动中的应用层业务需要与传输策略的分层和解耦，于 2019 年自研外部公有的传输层协定 Agora Universal Transport（AUT），将异构网络下的各种传输控制能力汇聚起来，并于 2021 ~ 2022 年开始逐渐大规模落地在各项业务中，用一套传输协定/框架解决各项业务不同的传输需要。 相干内容分为高低两篇，本文将具体介绍 AUT 传输协定的设计和演进过程。 01 纷繁复杂的传输场景作为一家提供实时互动平台的公司，传输毫无疑问是所有互动的基石，随着网络的倒退，互动的场景也越来越多样，传输的内容也越来越简单，实时互动下的传输次要面临以下需要和挑战： 媒体数据传输RTC 声网最次要的实时互动场景，实时音视频的传输也是和下层业务逻辑耦合最为严密的传输场景，传输逻辑须要与媒体层面的信源编码紧密配合实现低提早的互动。 ● 须要有一个牢靠的网络通道，来实现管制音讯的收发。 ● 须要有多个牢靠的实时通道，来满足多路数据流（音视频等）的收发。 ● 在带宽受限时，须要解决上述流的优先级治理问题（管制通道>音频>视频）。 ● To B 场景下，要能让客户自主灵便地决定流的优先级和传输降级策略。 ● 媒体中的相干策略，须要与以后的网络情况紧密配合。 ● 在网内传输时，不同地区间和运营商间互通的网络品质迥异，各种网络 buffer、提早及丢包相差微小。 通用数据传输声网推出的 FPA 全链路减速产品在寰球范畴为各类利用（包含 Web/游戏/音视频等）提供端到端的链路减速服务。 ● 同时反对端到端的牢靠传输通道和不牢靠传输通道。 ● 作为通用数据减速通道，数据流量变动范畴较大。 ● 低提早。 低提早可靠消息传输RTM 是声网对外提供的稳固牢靠、超低延时、高并发的寰球信令与音讯云服务。 ● 音讯体积小，音讯频率较高，整体流量绝对较低。 ● 低提早。 低优先级牢靠数据传输Report 是声网外部的埋点和事件数据上报，对内和对外提供问题排查的信息。 ● 传输优先级和实时性要求低，要防止对其余业务数据产生影响。 ● 与后端放弃长连贯，连贯数量微小，但绝大部分工夫闲暇。 各项业务网内传输SD-RTN™是声网外部的寰球笼罩网络，笼罩200多个国家和地区，承载着不同业务的流量。 ● 跨区传输中长肥链路（亦即长肥网络，带宽提早积大、丢包率高）的传输，大链路提早下的带宽俯冲/丢包要迅速复原。 ● 不同国家/运营商之间的网络品质难以保障，丢包/抖动非常常见。 ● 不同业务/客户/场景的不同水平 QoS 保障。 02 解决之道--自研传输层协定现有计划的有余传输需要各有不同，咱们首先 review 业界的各项产品，以求取得成熟的解决方案，但只管调研发现均存在各种不满足的中央： ...

华为HCIE这么多的认证方向，哪个方向最有价值，含金量最高？ 这个问题是很多入行网络工程师面临的问题之一，这个问题的实质其实就是在说这么多的方向，哪个方向才是华为做的最好的！ 首先要理解认证方向这个概念最先是由思科提出的，思科率先将网络分为了六大畛域。第一个就是大家个别都最先理解到，也最熟知的数通方向，华为叫做数通（Routing & Switching），思科叫做路由替换，数通是指华为的数据通信方面，目前次要数通的产品个别指企业级的路由器、外围交换机等网络设备，次要是面向外围网络和传输网络。而后还有网络安全（Security），而后还要运营商级别的方向，叫做ISP（是Internet Service Provider的简写，翻译为互联网服务提供商），接着还有无线方向（Wireless），最初一个是语音/视频合作方向（Collaboration），这些是由思科提出并划分的六个畛域。 上面再说说华为，华为的IE认证方向更多，且分类更细，除了数通/平安、云计算、存储、大数据这些大家常见且比拟熟知的之外，还有物联网、人工智能、网络对立通信、云服务、数据中心基础设施、智能计算、网络视讯、数据中心基础设施。即便是数通，华为也辨别了企业网数通和传输数通，总之分类是十分细的。然而在华为泛滥的认证方向中，做的最好的仍旧是数通。 值得一提的是，当初数通曾经改版降级为DATACOM，所以大家看到HCIE-R&S和HCIE-DATACOM时可能会认为这两个是两个不同方向的认证，其实后者是从前者降级而来，内容一脉相承，并且新增了更多对于SDN和网络自动化的内容。 大家有想理解和下载最新的HCIE认证考试内容纲要的话，能够私信或者评论区回复我获取新版纲要。 回到华为数通，华为认证目前出货量最大的仍然是数通方向，也就是当初的DATACOM方向，因为在任何一个网络我的项目中，路由器和交换机的使用率依然是最大的，能够说在整个网络架构中，路由器和交换机是整个网络的根底，这也就意味着以负责数据通信设施的测试验证工作的数通方向人才，是整个网络行业的外围。能够说，数通是整个网络体系的骨骼，其余所有的认证方向，都是承载在骨骼之上的血肉筋脉。如果整个网络架构中，没有路由器和交换机，则连通都做不到，就更不要提平安，因为不能架构防火墙，也没有服务或者协同可言。所以网络要害的是连通，而连通最须要的是设施是路由器和交换器，而其余所有的技术都围绕在路由器和交换机这两个设施之上，所以数通是整个网络行业最外围的方向。 所以大家在思考抉择华为认证或者思科认证的方向时，首先必须搞定数通方向或者说路由替换方向，拿下数通方向证书，再思考其余的方向。

前言对于计算机网络方面的内容，我比拟苦恼，该如何组织内容，将这部分内容如何和本人对网络编程的认知联合起来，还有就是介绍程序，引论之后是依照大学教材的程序，还是跳过物理层(这一层离程序员的确有点远，所以这部分内容不思考介绍)，数据链路层、网络层，应用层，还是自顶向下，应用层、传输层、网络层、数据链路层。这其实也是在取舍，因为我大学上这门课的时候，教材的程序是自下往顶， 而后我听了大略几个星期之后，齐全抉择放弃，因为听不懂，我感觉这些货色摸不到，我失去的只是一些形象的概念，落不了地，也可能跟过后没有做过网络开发的工作相干，在毕业之后实习，写了一点网络编程的代码，才缓缓了解起大学教材的概念，所以这也是这个系列会交叉一点网络编程框架介绍的起因。明天在应用层、网络层、传输层，这三层斟酌了颇长时间，最终还是决定先写TCP相干的内容。 咱们回顾一下在《计算机网络引论》外面的内容， 看似简略而又日常的网络通信，其实是一个简单的问题，为了升高问题的复杂度，计算机网络的先驱们，采取了分层的策略来解决通信过程中所遇到的问题，国际化规范组织于1977年成立了专门的组织来钻研该问题，该组织提出的分层计划是将网络分为七层 ， 因为该模型比拟理想化，最终没被市场所采纳，最终风行的是TCP/IP协定的四层规范，在学习计算机网络原理的时候往往采取折中的计划，将网络分为五层。 五层协定的体系结构只是为介绍网络原理，理论利用还是TCP/IP协定的四层体系结构。咱们自顶向上再来大抵的介绍一下各层的职能划分，加深记忆。 物理层: 规定电气个性，多大的电压代表“1”或“0”等数据链路层: 两台计算机之间的数据传输总是在一段一点的链路上传送的，这就须要专门的链路层的协定。在两个相邻结点之间传送数据时，数据链路层 将网络层交下来的数据包组装成帧，每一帧包含数据和必要的管制信息(如同步信息、地址信息、差错控制等)。 这样说可能有点形象，咱们来讲一个小故事来领会一下: 杨贵妃喜爱吃香蕉，皇帝为了让爱妃吃的开心，皇帝命令大臣日夜兼程将香蕉从海南运输到长安。 那么香蕉从海南到长安总共须要几步: 第一步: 首先须要用船将香蕉运出岛，运到广东的码头。 第二步: 从广东运向长安，这个时候还没有飞机，所以两头会坐船，骑马，换乘交通工具。 第三步: 香蕉达到目的地。 如果将士兵比喻成IP包，则马、船只就是数据链路层，这也就是IP包每一跳须要更换数据链路层，就如同士兵须要一直变换交通工具一样天然，局势所迫。 那为什么士兵会抉择将香蕉运到广东，从广东再运到长安，而不是运到非洲再运到长安呢，因为你广东离长安更近啊。 那为什么士兵不间接奔向长安？ 而是先到广东码头，因为码头是必经之地，码头是通向目的地长安的一块跳板，只管不是最终目的地，但士兵(IP包)却须要通过它。 如果有飞机呢，士兵是不是能够直飞长安呢，在这里飞机同样是数据链路层，因为它的目标是服务士兵(IP) 包，而士兵最终的目的地：长安。 网络层:在《计算机网络引论》中，咱们讲到IP层还有一个相似于理论住址的性能，便于动静路由，mac地址像是身份证，而IP层的IP则像是理论住址一样。 但其实这个必须还是有不失当的中央，这事实上把一部分传输层的性能也划入了网络层，mac地址更像是房间的地址，房子一旦建成，经度纬度不会再发生变化了。快递达到理论寓居房间之后，外面有好多人，那怎么确定这个快递是谁的呢，这就是传输层的工作之一。 传输层有了IP、MAC地址，还是无奈确定这个数据包要给哪个过程，运输层提出了端口的概念，通过IP+端口即可确定这个数据包能够给谁，相似于快递到房间之后，会叫名字，因为名字不是惟一的，快递员还会复核一下手机号。但快递的货色失落了怎么办，让卖家再发一次喽，尽管在运输过程中都是在尽最大致力交付，然而在运输过程中还是可能产生丢数据包的景象，个别的买家会让卖家再重发，这样的买家和卖家是TCP协定， 但有的买卖双方是丢了也不给你重发，也就是UDP协定。应用层有了快马加鞭运输系统，皇帝小孩儿个别是不怎么放心运输问题的，有的时候皇帝会发旨意，有的时候会发赏赐，这也就是利用过程之间的交互。TCP 概述连贯治理TCP是TCP/IP体系中非常复杂的一个协定，TCP是面向连贯的运输层协定，这就是说应用程序在应用TCP协定之前，必须先建设TCP连贯，在数据开释完之后，必须开释曾经建设的TCP连贯。其实在学到这个TCP连贯的时候，我对这个连贯多多少少是感觉了解不透的，我将其了解为通信之前确认通信单方的状态，打电话的时候有个拨号的过程，然而对面挂断电话的话，这个打电话界面也就退出了，这个我是了解的，然而这个连贯我就了解不到实体上，哪个是电话，拨号过程在哪里？再有，我如何去应用TCP协定，TCP协定是蛮简单的一个协定，我要编写通信软件不会还要我本人去实现一把这个协定吧。 当然不会让程序员用高级语言再实现一把TCP协定，这是一个宏大而又简单的工程，TCP/IIP协定曾经驻留在操作系统中，因为TCP/IP协定被设计成能运行在多种操作系统的环境中，因而TCP/IP协定规范没有规定应用程序与TCP/IP协定如何接口(调用)的细节，而是容许零碎设计者可能抉择无关API的具体实现细节。 目前来说只有几种可供应用程序应用的TCP/IP的利用程序接口，最驰名的就是美国加利福利亚大学伯克利分校为Berkeley UNIX操作系统定义的API，被称为套接字接口(socket interface)。微软在其操作系统中采纳了套接字 API，然而有一点不同，咱们称之为Windows Socket。AT&T的Unix System V版本定义的接口，简写为TLI(Transport Layer port) 因为有不同的实现，所以在不同的操作系统上行为可能会有点差别，也就是在TCP/IP协定上做独自的定制，但最终都实现了TCP/IP协定，次要的行为不会有差别。操作系统对外部裸露运输层和应用层通信的接口，个别咱们称之为Socket API。个别高级语言都留有调用操作系统Socket API的实现。咱们用Java来演示一下调用操作系统提供的运输层TCP协定: public class SocketClient{ public static void main(String[] args) throws Exception { // 这行代码会尝试和我本地端口为12345建设连贯 // 如果始终追着看会发现,最终调的是一个native办法 // 最终还是调的操作系统的办法 // 由操作系统返回是否可能建设连贯、连贯状态 Socket socket = new Socket("127.0.0.1",12345); }}这就相似于打电话了，通信之前，确认信道的品质。少数与TCP相干的文章都会从三次握手和四次握手登程，这里我试图先大抵描绘出TCP的主体，再别离去介绍TCP的各个局部。连贯治理也是TCP协定中的一个重要局部。 ...

一、HTTPS危险 1.1 危险一: 网络嗅探与监听用wireshark抓包时发现，路径终端ip的所有http报文都能够以明文形式被间接捕捉，包含但不限于用户名、明码、报表数据等。 本地src = 10.252.18.21，天枢服务器desc = 172.28.63.46。浏览器通过post形式向服务器发动申请：服务器返回数据：思考：不应用https的状况下，应该如何解决客户端输出的口令/提交的表单以保证数据机密性？前端：将明文数据用md5哈希;将哈希过的密文拼上一段随机生成的, 固定长度的盐;将上一步的后果应用后端的公钥加密并传递给后端. 后端：将前端传递过去的密文用私钥解密;去盐。因为盐是固定长度的, 所以间接裁剪即可;再次随机生成一段盐;将第2步去盐后的明码拼上第3步生成的盐, 并作 md5 哈希;将第4步的后果和第3步生成的盐存入数据库； 验证明码的时候, 后端只需将第2步去盐后的明码拼上从数据库中获得的盐, 作 md5 哈希后与数据库中的明码相比拟即可。 1.2 危险二：身份认证不足校验，存在中间人攻打。 1.3 危险应答措施信息加密HTTP 交互信息是被加密的，第三方就无奈被窃取。校验机制校验信息传输过程中是否有被第三方篡改过，如果被篡改过，则会有正告提醒。身份证书证实通信单方身份的真实性。二、HTTPS协定2.1 HTTPSHTTPS 协定是由 HTTP 加上 TLS/SSL 协定构建的可进行加密传输、身份认证的网络协议，次要通过数字证书、对称加密、非对称加密等技术实现互联网数据传输加密，实现互联网传输平安爱护。 设计指标次要有三个。（1）机密性（通过对称加密实现）：保障传输数据内容不会被第三方通晓。就像快递员传递包裹一样，都进行了封装，他人无奈获知外面装了什么。 （2）完整性（通过数字签名/哈希实现）：保障传输数据内容没有被第三方篡改。就像快递员尽管不晓得包裹里装了什么货色，但他有可能中途掉包，数据完整性就是指如果被掉包，咱们能轻松发现并拒收。 （3）可靠性（通过非对称加密实现）：保障传输数据内容只会被指定有权限的通信方收到。就像咱们邮寄包裹时，尽管是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错中央，通过身份校验来确保送对了中央。 2.2 SSLSecure Socket Layer，安全套接字协定，用以保障在Internet上数据传输的平安，利用数据加密技术，保障传输数据的机密性、完整性、可靠性。 SSL是一个不依赖于平台和使用程序的协定，位于TCP/IP协定与各种应用层协定之间，为数据通信进步平安反对。 SSL协定次要分为两层： （1）SSL握手协定层：包含SSL握手协定（SSL HandShake Protocol）、SSL明码参数批改协定（SSL Change Cipher Spec Protocol）和SSL告警协定（SSL Alert Protocol）。握手层的这些协定用于SSL治理信息的替换，容许利用协定传送数据之间互相验证，协商加密算法和生成密钥等。 （2）SSL记录协定层：为高层协定提供根本的平安服务。SSL纪录协定针对HTTP协定进行了特地的设计，使得超文本的传输协定HTTP可能在SSL运行。纪录封装各种高层协定，具体实施压缩解压缩、加密解密、计算和校验MAC等与平安无关的操作。 2.3 TLSTLS（Transport Layer Security，传输层平安协定）建设在SSL 3.0协定标准之上，是SSL 3.0的后续版本。与SSL次要的区别在于反对的加密算法不同。TLS对于安全性的改良： 1）对于音讯认证应用密钥散列法：TLS 应用“音讯认证代码的密钥散列法”（HMAC），当记录在凋谢的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控音讯认证，但HMAC比SSLv3.0应用的（音讯认证代码）MAC 性能更平安。 2）加强的伪随机性能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF应用两种散列算法保障其安全性。如果任一算法裸露了，只有第二种算法未裸露，则数据依然是平安的。 3）改良的已实现音讯验证：TLS和SSLv3.0都对两个端点提供已实现的音讯，该音讯认证替换的音讯没有被变更。然而，TLS将此已实现音讯基于PRF和HMAC值之上，这也比SSLv3.0更平安。 4）统一证书解决：与SSLv3.0不同，TLS试图指定必须在TLS之间实现替换的证书类型。 5）特定警报音讯：TLS提供更多的特定和附加警报，以批示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。 三、加解密算法 3.1 非对称加密3.1.1 特点加密密钥≠解密密钥，公钥和私钥之间存在数学上的配对关系。 公钥：公开的，用于加密或者验签。应用公钥加密的数据，只能应用对应私钥解密私钥：机密的，用户解密或者签名。应用私钥签名的数据，能够应用对应的公钥验签。 3.1.2 加密机制公钥明码：公钥加密失去密文，私钥解密失去明文音讯。数字签名)：私钥加密生成签名，公钥解密验证签名TLS罕用非对称加密、密钥协商算法：TLS罕用签名算法：ECDSA具体：https://zhuanlan.zhihu.com/p/66794410 ECC（ECDSA）与RSA 相比，有以下的长处：a. 雷同密钥长度下，平安性能更高，如160位ECC曾经与1024位RSA、DSA有雷同的平安强度。b. 计算量小，处理速度快，在私钥的处理速度上（解密和签名），ECC远 比RSA、DSA快得多。c. 存储空间占用小 ECC的密钥尺寸和零碎参数与RSA、DSA相比要小得多， 所以占用的存储空间小得多。d. 带宽要求低使得ECC具备宽泛得利用前景。 ...

千兆网线是指适宜千兆网络的网线，百兆网线是指适宜百兆网络的网线。依据具体电线，个别千兆网线指的是超五类以上的网线，百兆网线指的是五类网线。 目前支流的网线有哪些品种 目前支流的网线有五类线、超五类线、六类线、超六类线、七类线。 五类线：最常见的网线，没有什么特点，五类外皮会标注“CAT5”字样。 反对百兆以太网 超五类线：其实长的和五类线一样，超五类外皮标注“CAT5e”字样反对千兆以太网但个别只利用在100mbps的网络中，最高网速可达1024mbps，只实现桌面交换机到计算机的连贯，因为超五类非屏蔽网线要借助价格昂扬的非凡设施的反对。 反对千兆以太网 六类线：六类网线的"六类"个别是指六类非屏蔽双绞线，它的各项参数都有大幅提高，带宽也扩大更高。六类线外皮会标注“CAT6”字样。反对网速1 次要利用在千兆位网络中。 反对/千兆以太网 超六类线：超六类网线的网线外皮会标注“CAT6e” 超六类网线也叫6A线，能反对万兆上网，速率是六类网线的两倍以上。传输频率是200～250 MHz，最大传输速度也可达到10Gbps，次要利用于千兆位网络中。 反对千兆/万兆以太网 七类线：七类网线的网线外皮会标注“CAT7”它反对高达 10 Gbps 的高速以太网通信，Cat7 电缆向后兼容 Cat6、Cat5 和 Cat5e 电缆类别，它应用屏蔽电缆提供 100 米长的 4 连接器通道，并设计用于以 600 MHz 的频率传输信号。 反对千兆 / 万兆以太网 网线理论中能够依据这些外观来判断，厂商也会思考到消费者的需要，把线的类型印在外表，如图所示： 网线接线办法 1、百兆网线和千兆网线的接法一样。 2、百兆网线和千兆网线的接法完全相同，都是依照T568A或T568B规范接线，网线两边同时采纳T568A或T568B规范接线为直通线，次要用于不同网络设备的连贯，网线两边别离采纳T568A和T568B规范接线为穿插线，次要用于同类网络设备的连贯。 3、个别网线的两端能够都采纳T568B规范线序白橙橙白绿蓝白蓝绿白棕棕进行接线，也能够依照T568B规范白绿绿白橙蓝白蓝橙白棕棕接线。依照T568B或T568A规范接线，次要还是屏蔽网络信号串扰，进步网络信号传输的品质。

第一节 计算机网络利用体系结构从体系结构角度能够分为：客户/服务器（C/S）构造，纯P2P（Peer to Peer）构造和混合结构3种类型。一，客户/服务器（C/S）构造网络应用C/S构造的网络应用是最典型，最根本的网络应用。网络应用的通信单方分为服务器程序和客户程序，服务器程序须要先运行，做好通信的筹备，客户程序后运行，被动申请与服务器进行通信。C/S网络应用最次要的特色是通信只在客户与服务器之间进行，客户与客户之间不进行间接通信。在C/S通信过程中，被动发动通信的一方就是客户，被动承受通信的一方就是服务器。二，纯P2P构造网络应用在文件散发，文件共享，视频流服务等利用中，P2P利用体现出优越的性能，如Gnutella,BitTorent等。在纯P2P网络应用中，没有始终在运行的传统服务器，所有通信都是在对等的通信方之间间接进行，通信单方没有传统意义上的客户与服务器之分，“位置”对等。P2P利用中的每个对等端都同时具备C/S利用的客户与服务器的特色，是一个服务器与客户的结合体。事实上，P2P利用中的对等端软件包含服务器软件与客户端软件。在P2P利用中，对等端都是动静退出或来到利用，新退出的对等端须要晓得有那些对等端在线，在线对等端的地址以及在线对等端提供的服务等，这是P2P利用须要解决的关键问题之一。对于纯P2P利用，因为没有核心服务器，所以解决这些问题就更为艰难。三，混合结构网络应用混合结构网络利用将C/S与P2P利用相结合，既有核心服务器的存在，又有对等端（客户）间的间接通信。在混合结构网络应用中，存在客户（即对等端）与服务器之间的传统C/S构造的通信，也存在客户之间间接通信。通常每个客户通过C/S形式向服务器注册本人的网络地址，申明可共享的资源或可提供的服务，并通过核心服务器发现其余在线的客户，检索其余客户能够共享的资源等信息。第二节 网络应用通信基本原理网络应用的根本通信过程就是运行在不同主机上的利用过程间以C/S形式进行的通信。在C/S构造的网络应用中，服务器端运行的是服务器过程，被动地期待客户申请服务；客户端运行的是客户过程，被动发动通信，申请服务器过程提供服务。利用过程间遵循应用层协定替换应用层报文M。应用层协定定义了利用过程间替换的报文类型，报文形成局部具体含意以及替换时序等内容，即语法，语义和时序等协定三要素内容。从应用层角度来看，利用过程之间遵循应用层协定就能够间接实现端到端的报文M的替换，然而，本质通信过程并非如此。无论是服务器过程还是客户过程，当其遵循应用层协定组织好应用层报文后，须要通过层间接口（如利用编程接口API）将报文传递给相邻的传输层，申请传输层协定提供的端到端传输服务。典型的网络应用编程接口是套接字（Socket）。应用程序能够通过创立套接字实现与底层协定接口，并能够进一步通过套接字实现利用过程与底层协定之间的报文交换。因而，套接字是每个利用过程与其余利用过程进行网络通信时，真正收发报文的通道。一个利用过程能够创立多个套接字与同一个或不同的传输层协定进行接口。对于一个传输层协定，须要为与其接口的每一个套接字调配一个编号，标识该套接字，该编号称为端口号（port number）。通常服务器过程套接字会调配特定的端口号，而客户过程的套接字会绑定一个随机的惟一端口号。尤其是标准化利用，规范为不同的服务器调配了不同的默认端口号，Web服务器的默认端口为80，这部分端口号称为熟知端口号（well-known port munber）。每个利用过程通过一个或多个套接字与传输层协定进行接口，通过过程运行的主机IP地址以及其套接字所绑定的端口号能够标识利用过程。第三节 域名零碎（DNS）DNS（Domain Name System）是一个重要的根底利用，因为任何一个须要应用域名进行通信的网络应用，在利用通信之前首先须要申请DNS利用，将域名映射为IP地址。实现将域名映射为IP地址的过程，称为域名解析。DNS为了实现域名解析，须要建设分布式数据库，存储网络中域名与IP地址的映射关系数据，这些数据库存储在域名服务器上，域名服务器依据用户的申请提供域名解析服务。一，层次化域名空间因特网采纳了档次树状构造的命名办法，任何一个连贯在因特网上的主机或路由器，都能够有一个惟一的层次结构的域名。 ==国家顶级域名nTLD==：cn标识中国，us示意美国，uk示意英国等。==通用顶级域名gTLD==：最早的顶级域名是com（公司和企业），net（网络服务机构），org（非盈利组织），edu（专用的教育机构），gov（专用的政府部门），mil（专用的军事部门），int（国内组织）。==根底构造域名（infrastructure domain）==：这种顶级域名只有一个，即arpa，用于反向域名解析，因而又称为反向域名。二，域名服务器一个服务器所负责管辖的（或有权限的）范畴叫做区（zone）。每个区设置相应的权威域名服务器，用来保留该区中的所有主机的域名到IP地址的映射。域名服务器依据其次要保留的域名信息以及在域名解析过程中的作用等，能够分为根域名服务器，顶级域名服务器，权威域名服务器，两头域名服务器4类。任何一台主机在网络地址配置时，都会配置一个域名服务器作为默认域名服务器，这样这台主机任何时候须要进行域名查问，都会将域名查问申请发送给该服务器；该服务器如果保留了被查问域名的信息，则间接做出响应，如果没有，则代理服务器查问其余域名服务器，直到查问到后果，最初将查问后果发送给查问主机。这个默认域名服务器通常称为本地域名服务器。是主机进行域名查问过程中首先被查问的域名服务器。根域名服务器是最重要的域名服务器。寰球互联网中部署了无限的几个根域名服务器，每个根域名服务器都晓得所有的顶级域名服务器的域名和IP地址。不论是哪一个本地域名服务器，若要对因特网上任何一个域名进行解析，只有本人无奈解析，就首先求助于根域名服务器。==在因特网中共有13个不同IP地址的根域名服务器，名字是用一个英文字母名，从a始终到m==。顶级域名服务器，即TLD服务器，负责管理在该顶级域名服务器注册的所有二级域名。顶级域名服务器的名称对应一个域名的最初一个名字，是对一个行业的命名，或对一个区域的命名。权威域名服务器，负责一个区的域名服务器，保留该区中的所有主机的域名到IP地址的映射。 任何一个领有域名的主机，其域名与IP地址的映射关系等信息都存储在所在网络的权威域名服务器上。在档次域名构造中，有时还存在一些既不是根域名服务器，又不是顶级域名服务器，也不是权威域名服务器的域名服务器，这些域名服务器通常称为两头域名服务器。三，域名解析过程域名解析分为递归解析和迭代解析。提供递归查问服务的域名服务器，能够代替查问主机或其余域名服务器，进行进一步的域名查问，并将最终解析后果发送给查问主机或服务器。提供迭代查问的服务器，不会代替查问主机或其余域名服务器，进行进一步的查问，只是将下一步要查问的服务器告知查问主机或服务器。通常本地域名服务器都提供递归查问服务。主机在进行域名查问时，本地域名服务器如果没有被查问域名的信息，则代理主机查问根域名服务器或其余服务器，直到失去被查问域名的IP地址，最初将解析后果发送给主机。 提供迭代查问服务的域名服务器不会代理客户的查问申请，而是将最终后果或者下一步要查问的域名服务器间接响应给查问客户。根域名服务器通常只提供迭代查问服务，当根域名服务器收到本地域名服务器的迭代查问申请报文时，要么给出所要查问的IP地址，要么在响应报文中通知本地域名服务器下一步该当查问哪一个域名服务器，本地域名服务器则持续查问下一个域名服务器，直到查问到被查问域名主机的权威域名服务器。 无论是递归解析还是迭代解析，只有本地域名服务器不能间接响应解析后果，则都须要从根域名服务器开始查问。会重大影响查问响应工夫和查问效率，解决办法： 域名服务器减少缓存机制：即在为客户做出响应的同时，每个域名服务器会将在域名解析过程中解析到的后果存储到域名数据库中，当再次收到雷同域名信息的查问申请时，便能够利用缓存的信息间接做查问响应，从而缩短域名查问的工夫。第四节 万维网利用一，HTTP1，HTTP连贯HTTP基于传输层的TCP传输报文。浏览器在向服务器发送申请之前，首先须要建设TCP连贯，而后能力发送HTTP申请报文，并接管HTTP响应报文。依据HTTP在应用TCP连贯的策略不同，能够分为非长久连贯的HTTP和长久连贯的HTTP。 非长久连贯是指HTTP客户与HTTP服务器建设TCP连贯后，通过该连贯发送HTTP申请报文，接管HTTP响应报文，而后断开连接。HTTP/1.0默认应用非长久连贯，每次申请传输一个对象都须要新建设一个TCP连贯。 为了进步或改善HTTP的性能，须要对HTTP/1.0的这种默认的非长久连贯应用形式进行优化，典型的优化技术包含两种。 并行连贯，通过建设多条并行的TCP连贯，并向发送HTTP申请和并行接管HTTP响应。并行连贯并不一定总能减小提早，放慢网页加载速度，并行连贯会减少客户端主机的资源开销，零碎通常对同时建设的并行TCP连接数有限度。长久连贯，重用已建设的TCP连贯发送新的HTTP申请和接管HTTP响应，从而打消新建TCP连贯的工夫开销。长久连贯又分为两种工作形式：非流水形式长久连贯和流水形式长久连贯。 非流水形式长久连贯：也称为非管道形式长久连贯，客户端在通过长久连贯收到前一个响应报文后，能力收回对下一个对象的申请报文。。与非长久连贯相比，间断申请多个对象时，只需建设一次TCP连贯，这样，每获取一个对象只需一个RTT工夫。流水形式长久连贯：也称为管道形式长久连贯，客户端在通过长久连贯收到前一个对象的响应报文之前，间断顺次发送对后续对象的申请报文，而后再通过该连贯顺次接管服务器发回的响应报文。应用流水形式长久连贯时，获取一个对象均匀工夫远小于1个RTT工夫，如果疏忽对象传输工夫，间断申请的多个对象只需1个RTT工夫。HTTP/1.1默认状况下应用流水形式长久连贯。HTTP/1.1的长久连贯默认是激活的。如果心愿完结长久连贯，能够在报文中显式地增加connection: close首部行。HTTP/1.1应用长久连贯的次要束缚与规定 如果客户端不冀望在连贯上发送其余申请，则应该在最初一条申请报文中蕴含connection：close首部行。如果客户端在收到的响应报文中蕴含 connection：close 首部行，则客户端不能再在这条连贯上发送更多的申请。每个长久连贯只实用于一跳传输，HTTP/1.1代理必须可能别离治理与客户端和服务器的长久连贯。HTTP/1.1代理服务器不应该与HTTP/1.0客户端建设长久连贯。二，CookieHTTP服务器在向客户发送被申请的文件后，不保留任何对于该客户的状态信息，因为HTTP服务器并不保留对于客户的任何信息，所以HTTP被称为无状态协定（stateless protocol）。Cookie中文名称为小型文本文件，指某些网站为了分别用户身份，进行会话跟踪而存储在用户本地终端上的数据。Cookie由服务器端生成，发送给User-Agent（个别是浏览器），浏览器会将Cookie的key/value保留到某个目录下的文本文件内，下次申请同一网站时就发送该Cookie给服务器，Cookie次要包含4局部内容。 HTTP响应报文中的Cookie头行：Set-Cookie。通过Set-Cookie，发送通常不超过4KB的Cookie信息，包含为其用户调配的ID，用户对网站的拜访偏好等。用户浏览器在本地存储，保护和治理的Cookie文件。包含网站的域，门路，内容，有效期和平安5个字段。HTTP申请报文中的Cookie头行：Cookie。当用户向曾经拜访过且曾经取得Cookie信息的网站发送HTTP申请报文时，浏览器会自动检索本地的Cookie文件，并在每个申请报文中通过Cookie头行，携带上网站为该用户调配的Cookie信息。网站在后盾数据库中存储，保护Cookie信息，包含已调配给用户ID，每个ID用户在本网站的拜访特色等。Cookie常见的用处 网站利用Cookie的ID来精确统计网站的理论拜访人数，新访问者和反复访问者的人数比照，访问者的拜访频率等数据。网站利用Cookie限度某些特定用户的拜访。网站能够存储用户拜访过程中的操作习惯和偏好，对不同的用户提供不同的服务。记录用户登录网站应用的用户名，明码等信息，当用户屡次登录时，毋庸每次都从键盘输入。电商利用Cookie能够实现“购物车”性能。第五节 Internet电子邮件一，电子邮件系统构造电子邮件系统次要包含邮件服务器，简略邮件传输协定（SMTP），用户代理和邮件读取协定等。邮件服务器的性能是发送和接管邮件，同时还要向发信人报告邮件传送的状况，是电子邮件体系结构的外围。邮件服务器保护治理一个外出邮件队列，队列中暂存注册用户期待向外发送的邮件（发送基于SMTP）。当发送邮件时，邮件服务器首先从收件人邮箱地址中解析出接管邮件服务器的域名或IP，而后将邮件发送给邮件服务器，邮件服务器将接管到的邮件寄存到用户的邮箱中。用户代理（User Agent）是电子邮件利用的客户端软件，为用户提供应用电子邮件的接口。用户代理的次要性能是反对用户撰写，显示，解决和收发邮件，为用户浏览，回复，转发，保留和撰写邮件等提供编辑与操作环境。邮件服务器之间发送和接管邮件时依照客户/服务器形式工作。实现邮件服务器间发送邮件的利用层层协定是SMTP，用户代理向注册邮件服务器发送邮件时，通常也是基于SMTP。从客户/服务器通信形式来看，一个邮件服务器即能够看作客户，又能够看作服务器。一个邮件服务器通常至多蕴含两个过程（或线程）：邮件发送过程（mail sender）和邮件接管过程（mail receiver）。邮件接管过程实现SMTP的服务器端，通常绑定端口号25。邮件的发送与接管过程 用户A首先利用用户代理撰写邮件，而后基于SMTP将邮件发送到其注册的邮件服务器A的外出邮件队列中，期待邮件服务器发送。邮件服务器A从队列中取出用户A的邮件，基于SMTP发送给邮件服务器B。邮件服务器B将邮件寄存到用户B的邮箱中。在某个时刻，用户B利用用户代理连贯邮件服务器B上运行的邮件读取服务，基于邮件读取协定，将其邮箱中的邮件传输到本地，或者对邮箱中的邮件进行浏览，挪动等操作。二，SMTPSMTP是Internet电子邮件中外围应用层协定，实现邮件服务器之间或用户代理到邮件服务器之间的邮件传输。SMTP应用传输层TCP实现牢靠数据传输。SMTP邮件发送过程 SMTP客户端首先申请与服务器端的25号端口建设TCP连贯，连贯一旦建设，便开始进行SMTP应用层交互，实现邮件的发送。当TCP建设胜利后，SMTP通过3个阶段的应用层交互实现邮件的传输，别离是握手阶段，邮件传输阶段和敞开阶段。握手阶段：彼此申明本人的身份。邮件传输阶段：客户端首先向服务器端通告邮件发送者与邮件接收者的邮箱地址，而后开始邮件数据的传输。敞开阶段：申明邮件传输完结，并敞开TCP连贯。SMTP特点 SMTP只能传送7位ASCII码文本内容，包含SMTP命令，应答音讯以及邮件内容。因而，SMTP不能间接传送可执行文件或其余的二进制对象（如：图像，声音，视频等），包含许多其余非英语国家的文字（如：中文，俄文等），在通过SMTP传送这类内容时，必须将这些内容转换为7位的ASCII码文字模式。SMTP传送的邮件内容不能蕴含“CRLF.CRLF”，因为该信息用于标识邮件内容的完结，如果邮件内容中蕴含该信息，则SMTP在传输时，须要进行本义。SMTP是“推动”协定。当客户端有邮件发送给服务器时，客户被动与服务器（25号端口）申请建设TCP连贯，而后将邮件“推送”给服务器。SMTP应用TCP连贯是长久的。三，邮件读取协定目前Internet邮件系统中比拟风行的邮件读取协定有第三版的邮局协定（Post Office Protocol-Version 3，POP3），互联网邮件拜访协定（Internet Mail Access Protocol，IMAP）和HTTP，其中HTTP被用作Web Mail零碎中的邮件读取协定。1，POP3POP3是一个简略的邮件读取协定，为了保障读取邮件过程的可靠性，POP3协定应用传输层TCP。POP3客户端运行在用户代理中，POP3服务器运行在邮件服务器上，端口号为110。POP3交互过程分为3个阶段 受权（Authorization）：用户代理须要向服务器发送用户名和口令（以明文模式），服务器甄别用户身份，受权用户拜访邮箱。因为用户名和口令是明文传输的，所以安全性并不高。受权阶段次要有两个命令：user<user name> 和pass<password>，别离向服务器发送用户名和口令。事务处理：用户代理向服务器发送POP3命令，实现邮件读取，为邮件做删除标记，勾销邮件删除标记以及获取邮件的统计信息等操作。更新：客户收回了quit命令，完结POP3会话，服务器删除哪些被标记为删除的邮件。2,IMAPIMAP服务器将每个邮件与一个文件夹进行关联，当邮件第一次达到服务器时，与收件人的INBOX文件夹相关联。通过IMAP，收件人能够在服务器上创立新的文件夹，并能够对邮件进行挪动，查问，浏览，删除等操作。IMAP的一个重要特色是容许用户代理只读取邮件的局部内容。（当用户代理拜访IMAP服务器的网络带宽比拟低，或者想先看以下邮件主题再决定是否要下载整个邮件时，此个性十分有用）。3，HTTP当应用基于Web的邮件时，HTTP便被用于邮件的读取，此时HTTP也作为邮件读取协定应用。基于Web的电子邮件简称Web邮件（Web Mail）。Web邮件的长处之一是用户代理就是一般的Web浏览器。Web邮件与一般电子邮件系统的次要区别在于用户代理与邮件服务器之间的邮件收发不同，而邮件服务器与其余邮件服务器之间的发送和接管过程并没有区别，依然应用SMTP。第六节 FTP文件传输协定（File Transfer Protocol，FTP）是在互联网的两个主机间实现文件互传的网络应用，其应用层协定也称为FTP。FTP能够缩小或打消在不同操作系统下解决文件的不兼容性，屏蔽各计算机系统的细节，适宜在网络中任意异构计算机之间传送文件。FTP采纳C/S形式实现客户与服务器之间的双向文件传输。FTP的客户与服务器之间的交互以及文件传输过程均应用TCP的牢靠传输服务。用户通过FTP用户代理应用FTP利用，用户代理通过FTP客户与FTP服务器进行交互。FTP的服务器过程由两个大部分组成：一部分为主过程，负责接管新的客户申请；另一部分为若干个隶属过程，负责解决单个客户申请，与具体客户进行交互。FTP服务器能够同时为多个客户过程提供服务。用户在应用FTP服务时，首先客户过程须要申请与FTP服务器的21号端口建设一条TCP连贯，称为管制连贯，而后开始FTP会话。FTP会话之初，用户须要通过管制连贯向FTP服务器发送用户名和口令，进行零碎登录，通过服务器的受权后，客户才能够通过其余命令与服务器交互，包含申请将本地文件系统中的一个或者多个文件上传到近程文件系统，或者申请将服务器文件系统中的文件下载到本地。FTP特点 FTP的一个显著特点就是在传输文件时，须要建设一个数据连贯，专门用于文件传输，文件传输完结后，数据连贯即敞开。FTP利用应用两个“并行”的TCP连贯：管制连贯和数据连贯。 管制连贯在整个会话期间始终放弃关上，是长久的，FTP客户收回的传送申请通过管制连贯发送给服务器端的管制过程的端口（21），但管制连贯不用来传送文件，理论用于传输文件的是数据连贯，用来连贯客户端和服务器端的数据传送过程。数据传送过程理论实现文件的传送，在传送结束后敞开数据传送连贯，数据连贯是长期的，非长久的。服务器过程用本人传送数据的端口（20）与客户过程所提供的端口号建设数据连贯。管制连贯用于在客户与服务器之间传输管制信息，如用户标识，口令，扭转近程目录，上传文件，下载文件等命令。数据连贯用于理论传送文件内容因为FTP专门应用一个独立的管制连贯传输管制信息，与传输文件信息进行拆散，所以将FTP的这种管制信息的传送形式称为带外管制(out-of-band control)。与之对应，哪些命令，数据都是通过一个TCP连贯传输的应用层协定称为带内管制（int-band control）协定。FTP服务器必须在整个会话期间保留用户的状态，即FTP是有状态的（stateful）协定。第七节 P2P利用P2P体系的网络应用对服务器的依赖很小，甚至对于纯P2P来说，整个利用简直不依赖某个集中服务器，利用都是动静的在对等方之间进行。在P2P利用中，对等方随时可能退出利用，也随时可能来到利用，具备很强的利用规模伸缩性。P2P利用的对等方通常并不属于服务提供商，而是用户管制的桌面计算机或笔记本电脑等。P2P利用充沛汇集利用了端系统的计算能力以及网络传输带宽，代表了全新的网络应用架构与理念。第八节 Socket编程根底网络应用过程能够创立3种类型的Socket： 数据报类型套接字SOCK_DGRAM：面向传输层UDP接口。流式套接字SOCK_STREAM：面向传输层TCP接口。原始套接字SOCK_RAW：面向网络层协定（如IP，ICMP等）接口。 原始套接字的创立有权限限度，如，在Linux操作系统中，须要root权限的用户能力创立原始套接字。通过原始套接字，利用过程能够实现一些非凡的权限，如收发ICMP报文等。罕用Socket API函数 int socket(int family,int type,int protocol);性能： 创立套接字。参数： family为协定族，通常取值为PF_INET或AF_INET示意面向IPv4协定栈；type为套接字类型，取值SOCK_STREAM,SOCK_DGRAM,SOCK_RAW,别离为流式套接字，数据报套接字，原始套接字protocol为协定，其中取值IPPROTO_TCP，IPPROTO_UDP别离示意TCP协定和UDP协定。返回： 胜利，返回非负整数，为套接字描述符。失败，返回-1或SOCKET_ERROR。阐明： 创立指定类型的套接字。int close(int sockfd);性能： ...

第一节 计算机网络基本概念一，计算机网络的定义计算机网络是利用通信设施与通信链路或者通信网络，互连地位不同，性能自治的计算机系统，并恪守肯定的规定实现计算机系统之间信息替换。概括性的定义：计算机网络是互连的，自治的计算机的汇合。 “自治“是指互连的计算机系统彼此独立，不存在主从或者管制与被管制的关系。”互连“是指利用通信链路连贯互相独立的计算机系统。通信链路能够是双绞线，光纤，微波，通信卫星等。不同链路的传输速率也不同，在计算机网络中也被称为带宽，单位bit/s或bps或b/s。 定义中的”计算机“应了解为”计算机设备“。（能连贯网络的如智能设施，智能手表）。 计算机网络定义中的”自治计算机“，通常称为”主机“（host）或”端系统“（end System）。 只有是连贯到Internet上的设施，都能够被称为主机或端系统。 Internet Service Provider（ISP，网络服务提供商） 家庭用户端系统形成小型家庭网络，并借助电话网络，有线电视网络等接入区域或本地ISP。企业网络，校园网等机构网络，通常形成肯定规模的局域网，而后再接入区域或本地ISP。区域或本地ISP再与更大规模的国家级ISP互连，国家级ISP再互连其余国家级ISP或全球性ISP，实现寰球所有ISP网络的互连，从而实现全球性端系统的互连。ISP网络由许多有线或无线通信链路互连分组替换设施形成。分组替换设施能够实现数据分组的接管与转发，是形成Internet的重要根底，存在多种形式，最典型的是路由器和交换机。Internet中互连的端系统，分组替换设施或其余网络设备在进行信息发送，接管或转发的过程中，都须要遵循网络协议。二，协定的定义协定约定了实体之间替换的信息类型，信息各局部的含意，信息替换程序以及收到特定信息或出现异常时应采取的行为。任何一个协定都会显式或隐式的定义3个基本要素：语法（syntax），语义（semantics）和时序（timing），称为协定三要素。 语法 定义实体之间替换信息的格局与构造，或者定义实体（如硬件设施）之间传输信息的电平等。语义 定义实体之间替换的信息中须要发送（或蕴含）哪些管制信息，这些信息的具体含意，以及针对不同含意的管制信息，接管信息端应如何响应。有的协定还须要进行过错检测，这类协定通常会在协定信息中附加过错编码等管制信息。语义还须要定义彼此采纳何种过错编码，以及采取何种过错解决机制等。时序 也称为同步，定义实体之间替换信息的程序以及如何匹配或适应彼此的速度。三，计算机网络的性能计算机网络的性能是在不同主机之间实现疾速的信息替换。通过信息替换，计算机网络可实现资源共享这一外围性能，包含硬件资源共享，软件资源共享和信息资源共享。1. 硬件资源共享通过计算机网络，一台主机能够共享另一台主机的硬件资源。云计算和云存储就是实现了硬件资源共享。2.软件资源共享网络上的主机能够近程拜访，应用服务器计算机上运行的各类大型软件，如大型数据库系统，大型行业专用软件等。软件资源的共享能够防止软件的反复投资，反复部署，无效节省成本。软件服务化，即通过互联网提供软件服务，不再销售软件，从而产生了软件即服务（Software as a Service，SaaS）。代表了软件共享的支流趋势。3.信息资源共享如政府的政策法规，企业的产品信息，社会热点新闻等。四，计算机网络的分类1. 按覆盖范围分类1. 个域网（Personal Area Network，PAN）通常是由集体设施通过无线通信技术形成小范畴的网络，实现集体设施间的数据传输。如通过蓝牙技术实现集体设施的互连等。个域网通常覆盖范围在1~10m。2. 局域网（Local Area Network，LAN）通常部署在办公室，办公楼，厂区，学校等部分区域内，采纳高速有线或无线链路连贯主机。局域网通常覆盖范围在10m~1km。3. 城域网（Metropolitan Area Network，MAN）指笼罩一个城市范畴的网络，覆盖范围通常在5~50km。4. 广域网（Wide Area Network，WAN）覆盖范围在几十到几千千米，通常逾越更大的天文空间，实现异地城域网或局域网的互连。2. 按拓扑构造分类网络拓扑是指网络中的主机，网络设备间的物理连贯关系与布局。1. 星形拓扑构造星形拓扑构造网络包含一个地方结点，网络中的主机通过点对点通信链路与地方结点连贯，地方结点通常是集线器，交换机等设施，主机间的通信都须要通过地方结点进行。罕用于局域网，个域网中。长处是易于监控治理，故障诊断与隔离容易；毛病是地方结点是网络的瓶颈，一旦故障，全网瘫痪，网络规模受限于地方结点的端口数量。2. 总线型拓扑构造采纳一条播送信道作为公共传输介质，称为总线，所有结点均与总线连贯，结点间的通信均通过共享的总线进行。因为总线是一条播送信道，所以任一结点通过总线发送数据时，其余结点都会接管到承载这些数据的信号。如果同时有两个或以上的结点同时向共享信道中发送数据，就会产生烦扰，会导致任何一个结点的数据发送失败，这一景象称为抵触。次要用于晚期的局域网长处是构造简略，所需电缆数量少，易于扩大；毛病是通信范畴受限，故障诊断与隔离较艰难，容易产生抵触。3. 环形拓扑构造利用通信链路将所有结点连接成一个闭合的环。环中的数据传输通常是单向传输，每个结点能够从环中接收数据，并向环中进一步转发数据。如果某结点判断数据是发送给本人的，则复制数据。数据会沿特定方向绕环一周，回到发送数据的结点，发送数据的结点须要负责从环中革除其发送的数据。罕用于晚期的局域网，园区网和城域网中。长处是所需电缆长度短，能够应用光纤，易于防止抵触；毛病是某结点的故障容易引起全网瘫痪，新结点的退出或撤出比拟麻烦。4. 网状拓扑构造网状拓扑构造网络中的结点通过多条链路与不同的结点间接连贯。如果网状拓扑构造网络中的任一结点与其余所有结点均有间接链路连贯，则称为齐全网状拓扑网络，否则称为非齐全网状拓扑网络。罕用于广域网，外围网络等。长处是网络可靠性高，一条或多条链路故障时，网络依然能够通。毛病是网络结构简单，造价老本高，选路协定简单。 5. 树形拓扑构造树形拓扑构造网络能够看作是总线型拓扑或星形拓扑网络的扩大。比拟多见的是通过级联星形拓扑构造网络中的地方结点构建树形拓扑构造网络。罕用于局域网长处是易于扩大，故障隔离容易。毛病是对根节点的可靠性要求高，一旦根节点故障，则可能导致网络大范畴无奈通信。6. 混合拓扑构造混合拓扑构造网络是由两种以上简略拓扑构造网络混合连贯而成的网络。绝大多数理论网络的拓扑都属于混合拓扑构造。如Internet。长处是易于拓展，能够构建不同规模网络。毛病是网络结构简单，治理与保护简单。3. 按替换形式分类电路替换网络报文交换网络分组替换网络4. 按网络用户属性分类1. 专用网（public network）指由国家或企业出资建设，面向公众提供免费或收费服务的网络。2. 公有网（private network）公有网指由某个组织出资建设，专门面向该组织外部业务提供网络传输服务，不面向公众凋谢的网络。第二节 计算机网络构造大规模古代计算机网络的构造包含网络边缘（network edge），接入网络（access network）与网络外围（network core）3局部。一，网络边缘连贯到网络上的计算机，服务器，智能手机，智能传感器，智能家居等称为主机或端系统。这些端系统位于网络的最边缘。连贯到网络上的所有端系统形成了网络边缘。网络边缘为网络用户提供了网络应用服务。二，接入网络接入网络是实现网络边缘的端系统与网络外围连贯与接入的网络。常见的有如下几类。1. 电话拨号接入利用电话网络，通过调制解调器（modem）将数字信号调制到模仿电话线路，通过电话网络的模仿语言信号作为载波传送到远端，再利用调制解调器将数字信号从模拟信号解调进去。长处：不便实现扩散的家庭用户接入网络。毛病：最大带宽通常只有56kbit/s。2.非对称数字用户线路ADSL电话机连贯电话端的线路称为用户线路（Subscriber Line）。ADSL（Asymmetrical Digital Subscriber Line）是利用现有的电话网络的用户线路实现的接入网络。ADSL基于频分多路复用（FDM）技术实现电话语音通信与数字通信（网络数据传输）共享一条用户线路。在进行网络通信的同时能够进行电话语音通信。在ADSL接入网络中，在用户线路上实现的上行（从用户端向网络上传数据）带宽比上行（从网络向用户端下传数据）带宽小。所以被称为“非对称”数字用户线路。ADSL存在很多规范，并且能够实现的上行和上行带宽与用户线路的长度有关系。ADSL罕用于家庭接入网络。3. 混合光纤同轴电缆HFC接入网络HFC（Hybrid Fiber-Coaxial）也称为电缆调制解调器（cable modem）接入，是利用有线电视网络实现网络接入的技术。用户端应用电缆调制解调器连贯有线电视网的入户同轴电缆，同轴电缆连贯到光纤结点，再通过光纤链路连贯电缆调制解调端接零碎，进而连贯网络。HFC基于频分多路复用技术，利用有线电视网络同轴电缆残余的传输能力实现电视信号传输与网络数据传输的共享。HFC也是“非对称”的，典型上行带宽为30.7Mbit/s，上行带宽为42.8Mbit/s。HFC接入是共享式接入，即连贯到同一段同轴电缆上（如同一个小区内）的用户共享上行和上行带宽。可见，当HFC共享用户数较大时，每个用户取得的理论带宽可能并不高。4.局域网企业，学校等机构会在组织范畴内建设局域网，连贯所有须要接入内部网络的主机，而后通过企业网络或校园网的边缘路由器连贯网络外围。5.挪动接入网络挪动接入网络次要利用挪动通信技术，如3G/4G/5G网络，实现智能手机，挪动终端等设施的网络接入。挪动接入网络是不可代替的，而且将成为集体设施接入网络的首选路径。三，网络外围网络外围是由通信链路互连的分组替换设施形成的网络，作用是实现网络边缘中主机之间的数据中继与转发。 比拟典型的分组替换设施是路由器和交换机等。相距边远的主机之间不可能通过一条物理通信链路间接连贯，而是各自通过接入网连贯到网络外围上，彼此传输数据都是通过网络外围进行中继与转发，最初送达目标主机。第三节 数据交换技术一，数据交换的概念替换设施具备多通信端口，能够同时连贯多个通信结点（即主机或替换设施），实现通信端口间物理或逻辑的动静，并行通信。通过替换设施，每个主机只需一个通信链路与替换设施相连，即可实现与其余主机的通信。 一个替换设施的端口是无限的，并且也无奈通过一条通信链路间接连贯间隔边远的主机或通信设施，因而，只有在非凡状况下，如小规模局域网，才有可能利用一个替换设施间接连贯所有主机。为了连贯更大范畴，更多数量的主机，能够将许多替换设施互连，形成一个数据中继与转发的“两头网络”，而后再将主机连贯到间隔较近的替换设施上，主机之间的数据传输通过“两头网络”实现中继与转发。这个两头网络不须要关怀所传输数据的内容，而只是为这些数据从一个结点到另一个结点直至达到目标结点提供数据中继与替换性能，因而，称为数据交换网络，组成替换网络的结点（即替换设施）称为替换结点，替换结点和传输介质的汇合称为通信子网，即网络外围。数据交换是实现在大规模网络外围上进行数据传输的根底技术。常见的数据交换技术包含电路替换（circuit switching），报文交换（message switching）和分组替换（packet switching）。二，电路替换电话网络是最早，最大的电路替换网络。电路替换中，首先须要通过两头替换结点为两台主机之间建设一条专用的通信线路，称为电路，而后再利用该电路进行通信，通信完结后再拆除电路。在通信过程中，替换设施对通信单方的通信内容不做任何干涉。应用电路替换进行通信包含建设电路，传输数据和拆除电路3个阶段。1.建设电路传输数据之前，必须建设一条端对端的电路，这个电路可能不是通信单方之间间接的连贯，而是通过若干个两头替换结点实现的连贯。如果两个主机之间须要进行通信，那么发送主机须要先收回呼叫申请信号给接管主机，而后通过若干结点沿途接通一条物理链路后，再由接管主机收回应答信号给发送主机，这样单方之间的电路连贯就建设胜利了。只有电路建设胜利之后，能力进入数据传输阶段。电路替换的“接续”过程所需工夫的长短与接续的两头替换结点的个数无关。电路建设之后在两个主机之间的每一段物理链路上都为单方的通信预留了相应的带宽，这个带宽在单方通信期间将始终保留并独占。2.传输数据被传输的数据能够是数字数据也能够是模仿数据，数据的传输能够是单工也能够是全双工。在发送主机和接管主机之间存在一条“独占”的物理线路为单方的本次通信服务。（“独占”指的是替换结点之间的线路是绝对独占的，因为通过信道复用技术对一条物理信道进行信道划分，而主机的替换结点之间的线路往往是相对独占的）。在本次通信完结之前，这条“独占”的物理线路上的所有资源不能被其余主机应用，即便某一时刻通信单方并没有数据进行传输。3.拆除电路拆除动作可由两个通信主机之间的任何一方发动并实现。开释信号必须传送到电路所通过的各个结点，以便重新分配资源。电路替换总结电路替换的特点是有连贯的，在通信时须要先建设电路连贯，在通信过程中独占一个信道，通信完结后拆除电路连贯。电路替换的长处是实时性高，时延和时延抖动都较小；毛病是对于突发性数据传输，信道利用率低，且传输速率繁多。电路替换实用于语音和视频这类实时性强的业务。三，报文交换报文交换也称为音讯替换，其工作过程为： 发送方把要发送的信息附加上发送/接管主机的地址及其他管制信息，形成一个残缺的报文（Message）。以报文为单位在替换网络的各结点之间以存储—转发的形式传送，直至送达目标主机。一个报文在每个结点的延迟时间，等于接管报文所需的工夫加上向下一个结点转发所需的排队延迟时间之和。“存储-转发”替换形式报文交换当时不须要建设连贯，发送方组装好报文之后即可向相邻的替换结点收回，替换结点收到整个报文并且查看无误后，临时存储报文，而后利用路由抉择找出须要转发的下一个结点的地址，再把整个报文转发给下一个结点。优缺点长处： 绝对电路替换信道而言，报文交换线路利用率高。毛病： 报文交换网络中替换结点须要缓冲存储，报文须要排队，因而会导致报文通过网络的延迟时间变长并且不固定，对于实时通信而言会容易呈现不能满足速度要求的状况。有时结点收到的报文过多而存储空间不够或者输入链路被占用不能及时转发时，就不得不抛弃报文。==古代计算机网络没有采纳报文交换技术的。==（时延较长，从几分钟到几小时不等）四，分组替换1.分组替换基本原理分组替换是目前计算机网络宽泛采纳的技术。分组替换须要将待传输数据（即报文）宰割成较小的数据块，每个数据块附加上地址，序号等管制信息形成数据分组（packet），每个分组独立传输到目的地，目的地将收到的分组从新组装，还原为报文。分组传输过程通常也采纳存储—转发替换形式。分组替换将一个残缺报文拆分成若干个分组，每个分组的长度有一个下限，无限长度的分组使得每个结点所需的存储能力升高，分组能够存储到内存中，进步了替换速度。2.分组替换长处替换设施存储容量要求低 报文交换须要缓存整个报文，当报文很大时，要求报文交换设施具备很大的存储容量。分组替换将大报文拆分为较短的分组进行传输。实践上讲，分组替换只有能存储一个小分组，网络就能工作。替换速度快 分组替换设施因为只须要缓存肯定数量的较短的分组，因而能够利用主存储器进行存储-转发解决，不需拜访外存，解决转发速度放慢。分组替换网络中，多个分组能够在网络中的不同链路上进行并发传送，大大提高传输效率和线路利用率。缩短整个报文通过网络的工夫。牢靠传输效率高 ...

简介咱们晓得WebSocket是建设在TCP协定根底上的一种网络协议，用来进行客户端和服务器端的实时通信。十分的好用。最简略的应用WebSocket的方法就是间接应用浏览器的API和服务器端进行通信。 本文将会深入分析WebSocket的音讯交互格局，让大家得以明确，websocket到底是怎么工作的。 WebSocket的握手流程咱们晓得WebSocket为了兼容HTTP协定，是在HTTP协定的根底之上进行降级失去的。在客户端和服务器端建设HTTP连贯之后，客户端会向服务器端发送一个降级到webSocket的协定，如下所示： GET /chat HTTP/1.1Host: example.com:8000Upgrade: websocketConnection: UpgradeSec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==Sec-WebSocket-Version: 13留神，这里的HTTP版本必须是1.1以上。HTTP的申请办法必须是GET通过设置Upgrade和Connection这两个header，示意咱们筹备降级到webSocket了。 除了这里列的属性之外，其余的HTTP自带的header属性都是能够承受的。 这里还有两个比拟特地的header，他们是Sec-WebSocket-Version和Sec-WebSocket-Key。 先看一下Sec-WebSocket-Version， 它示意的是客户端申请的WebSocket的版本号。如果服务器端并不明确客户端发送的申请，则会返回一个400 ("Bad Request")，在这个返回中，服务器端会返回失败的信息。 如果是不懂客户端发送的Sec-WebSocket-Version，服务器端同样会将Sec-WebSocket-Version返回，以告知客户端。 这里要特地关注的一个header字段就是Sec-WebSocket-Key。咱们接下来看一下这个字段到底有什么用。 当服务器端收到客户端的申请之后，会返回给客户端一个响应，通知客户端协定曾经从HTTP降级到WebSocket了。 返回的响应可能是这样的： HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=这里的Sec-WebSocket-Accept是依据客户端申请中的Sec-WebSocket-Key来生成的。具体而言是将客户端发送的Sec-WebSocket-Key 和 字符串"258EAFA5-E914-47DA-95CA-C5AB0DC85B11" 进行连贯。而后应用SHA1算法求得其hash值。 最初将hash值进行base64编码即可。 当服务器端返回Sec-WebSocket-Accept之后，客户端能够对其进行校验，已实现整个握手过程。 webSocket的音讯格局之所以要应用webSocket是因为client和server能够随时随地发送音讯。这是websocket的神奇所在。那么发送的音讯是什么格局的呢？咱们来具体看一下。 client和server端进行沟通的音讯是以一个个的frame的模式来传输的。frame的格局如下： 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload Data | +-------------------------------- - - - - - - - - - - - - - - - + : Payload Data continued ... : + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Payload Data continued ... | +---------------------------------------------------------------+MASK示意的是音讯是否是被编码过的，对于从client过去的音讯来说，MASK必须是1。如果client发送给server端的音讯，MASK不为1，则server须要断开和client的连贯。然而server端发送给client端的音讯，MASK字段就不须要设置了。 ...

简介服务端和客户端应该怎么进行通信呢？咱们常见的办法就是客户端向服务器端发送一个申请，而后服务器端向客户端发送返回的响应。这种做法比较简单，逻辑也很清晰，然而在某些状况下，这种操作形式并不好使。 比方在服务器端的某些变动须要告诉客户端的状况，因为客户端并不知道服务器端的变动是否实现，所以须要不停的应用轮循去检测服务器的状态。这种做法的毛病就是太过于浪费资源。如果心愿及时性好的话，须要一直的缩小轮循的工夫距离，导致极大的服务器压力和资源的节约。 那么有没有好的解决办法呢？ 既然不能应用查问，那么就改成服务器推送就行了。咱们晓得在HTTP/2中，提供了一种服务器推送的形式，然而这种形式是单向的，也就是说在同一个TCP连贯之上，并不能实现客户端和服务器端的交互。 于是咱们须要一个可能双向交互的网络协议，这个协定就是WebSocket。 webSocket vs HTTPwebSocket是一个基于底层TCP协定的一个双向通信网络协议。这个双向通信是通过一个TCP连贯来实现的。webSocket于2011年以RFC 6455公布成为IETF的规范。 同样作为基于TCP协定的标准协议，它和HTTP有什么区别呢？ 如果以OSI的七层模型来说，两者都位于七层协定的第四层。然而两者是两种不同的协定。鉴于HTTP曾经如此风行了，为了保障webSocket的通用性，webSocket也对HTTP协定进行了兼容。也就是说可能应用HTTP协定的中央也就能够应用webScoket。 这个和之前探讨的HTTP3有点相似，尽管HTTP3是一个新的协定，然而为了保障其宽泛的利用根底，HTTP3还是在现有的UDP协定上进行重写和构建。目标就是为了兼容。 实时上，webSocket应用的是HTTP upgrade header，从HTTP协定降级成为webSocket协定。 HTTP upgrade header什么是HTTP upgrade header呢？ HTTP upgrade header是在HTTP1.1中引入的一个HTTP头。当客户端感觉须要降级HTTP协定的时候，会向服务器端发送一个降级申请，服务器端会做出相应的响应。 对于websocket来说，客户端在和服务器端建设连贯之后，会首先发送给服务器端 Upgrade: WebSocket 和 Connection: Upgrade 头。服务器端接管到客户端的申请之后，如果反对webSocket协定，那么会返回同样的Upgrade: WebSocket和Connection: Upgrade 头到客户端。客户端接管到服务器端的响应之后，就晓得服务器端反对websocket协定了，而后就能够应用WebSocket协定发送音讯了。 websocket的长处其实后面咱们也讲过了，绝对于传统的HTTP拉取，webSocket能够借助于一个TCP连贯实现数据的实时传输。能够在缩小服务器压力的同时，实现服务器和客户端的实时通信。 webScoket的利用WebSocket应用的是ws和wss作为URI的标记符。其中ws示意的是websocket，而wss示意的是WebSocket Secure。 因为通常来说咱们应用的web浏览器来和服务器进行通信。浏览器就是咱们的web客户端，对于古代浏览器来说，基本上都反对WebSocket协定，所以大家能够释怀利用，不必放心协定兼容的问题。 对于浏览器客户端来说，能够应用规范的浏览器WebSocket对象，来和服务器进行通信，咱们看一个简略的javascript客户端应用webSocket进行通信的例子： // 应用规范的WebSocket API创立一个socket连贯const socket = new WebSocket('ws://www.flydean.com:8000/webscoket');// 监听webSocket的open事件socket.onopen = function () { setInterval(function() { if (socket.bufferedAmount == 0) socket.send(getUpdateData()); }, 50);};// 监听接管音讯事件socket.onmessage = function(event) { handleUpdateData(event.data);};// 监听socket敞开事件socket.onclose = function(event) { onSocketClose(event);};// 监听error事件socket.onerror = function(event) { onSocketError(event);};上述代码次要就是各种监听socket的事件，而后进行解决，非常简单。 ...

咱们曾经钻研了两个间接相连的主机进行通信须要什么。 咱们曾经钻研了主机通过交换机与另一台主机通信须要什么。 当初咱们增加另一个网络设备，看看流量通过路由器从主机传递到主机须要什么。 本文将是咱们将路由器视为数据包旅行中的要害参与者时所探讨的所有内容的理论利用。 在持续之前，可能值得查看该局部。 咱们将首先查看两个次要的路由器性能，而后在查看路由器操作时查看它们的运行状况。 通过这些概念探讨的形式，咱们将应用下图。 咱们将关注 R1，以及它将数据包从主机 A 转发到主机 B 和主机 C 须要什么。 为简略起见，每个 NIC 的 MAC 地址将缩写为4个十六进制数字。 路由器性能后面咱们提到路由器的次要目标是促成网络之间的通信。 因而，每个路由器都会在两个网络之间创立一个边界，它们的次要作用是将数据包从一个网络转发到另一个网络。 请留神，在上图中，咱们让 R1 在 11.11.11.x 网络和 22.22.22.x 网络之间创立了一个边界。 咱们让 R2 在 22.22.22.x 和 33.33.33.x 网络之间创立边界。 两个路由器在 22.22.22.x 网络中都有一个接口。 为了在网络之间转发数据包，路由器必须执行两项性能：填充和保护路由表，以及填充和保护 ARP 表。 填充路由表从每个路由器的角度来看，路由表是存在的所有网络的映射。 路由表开始时为空，并在路由器获知到每个网络的新路由时填充。 路由器能够通过多种形式学习每个网络的路由。 咱们将在本节中探讨其中的两个。 最简略的办法是所谓的直连路由。 实质上，当路由器接口配置了特定的 IP 地址时，路由器将晓得它间接连贯到的网络。 例如，在上图中，R1 的左侧接口配置了 IP 地址 11.11.11.1。 这通知 R1 11.11.11.x 网络的地位存在于其左侧接口之外。 同样，R1 获知 22.22.22.x 网络位于其右侧接口。 当然，路由器不能间接连贯到每个网络。 请留神，在上图中，R1 未连贯到 33.33.33.x，但很可能有一天它必须将数据包转发到该网络。 因而，必须存在另一种学习网络的形式，而不仅仅是路由器直连。 另一种形式称为动态路由。 动态路由是由管理员手动配置的路由。 就如同你明确通知 R1 33.33.33.x 网络存在于 R2 之后，为了达到它，R1 必须将数据包发送到 R2 的接口（配置了 IP 地址 22.22.22.2）。 ...

在上一篇文章中，咱们钻研了两台主机间接互相通信所产生的所有。 在本文中，咱们将增加一个常见的网络设备：交换机。 咱们将看看通过交换机从主机到主机的通信会产生什么。 本文将是咱们将交换机视为数据包传输中的要害参与者时所探讨的所有内容的理论利用。 在持续之前，可能值得查看该局部。 咱们将从查看交换机的各个性能开始，而后查看显示它们合作操作的动画。 交换机性能交换机次要有四个性能：学习、洪泛、转发和过滤 学习作为 L2 设施，交换机将依据 L2 报文头中的信息做出所有决定。 具体来说，交换机将应用源 MAC 地址和指标 MAC 地址来做出转发决策。 交换机的指标之一是创立一个 MAC 地址表，将其每个交换机端口映射到所连贯设施的 MAC 地址。 MAC 地址表一开始是空的，每次交换机收到任何货色时，它都会查看传入帧的源 MAC 地址字段。 它应用源 MAC 和接管帧的交换机端口在 MAC 地址表中建设一个条目。 迟早，随着每个连贯的设施不可避免地发送一些货色，交换机将领有一个齐全填充的 MAC 地址表。而后，该表可用于智能地将帧转发到其预约目的地。 洪泛然而，只管进行了上述学习过程，但不可避免的是，交换机在某些时候会收到发往交换机不晓得其地位的 MAC 地址的帧。 在这种状况下，交换机惟一的抉择是简略地复制帧并将其发送到所有端口。 此操作称为洪泛。 洪泛确保如果指标设施存在并且它连贯到交换机，那么它必定会收到帧。 当然，连贯到该特定交换机的所有其余设施也是如此。 尽管不现实，但这是齐全失常的。 每个连贯设施的 NIC 将接管该帧并查看指标 MAC 地址字段。 如果他们不是预期的接收者，他们只会默默地抛弃帧。 然而，如果它们是预期的设施，那么交换机能够释怀，晓得它可能胜利传送帧。 此外，当指标设施收到帧时，将生成一个响应，当发送到交换机时，该响应将容许交换机学习并创立一个 MAC 地址表，将未知设施映射到其交换机端口。 转发当然，现实状况下，对于遇到的每个指标 MAC 地址，交换机在 MAC 地址表中都有一个条目。 产生这种状况时，替换机会很快乐地将帧转发到适当的交换机端口。 交换机能够通过三种办法转发帧。 上面简要介绍它们。 存储和转发交换机将整个帧（header + data）复制到内存缓冲区中，并在转发之前查看该帧是否存在谬误。 这种办法是最慢的，但容许最好的谬误检测和其余个性，例如优先解决某些类型的流量以放慢处理速度。 直通交换机不存储任何内容，只查看读取指标 MAC 地址和转发帧所需的最低限度。 这种办法是最快的，但不提供谬误检测或附加性能的后劲。 无碎片这种办法是前两种办法的混合。 在转发帧之前，交换机仅查看帧的第一局部（64 字节）。 如果产生传输谬误，通常会在前 64 个字节内留神到。 因而，这种办法提供了“足够好”的谬误检测，同时取得了防止在转发之前将整个帧存储在其内存中的速度和效率。 ...

在探讨了 OSI 模型的组成以及将数据包从一台主机传输到另一台主机时所波及的一些要害参与者之后，咱们最终能够探讨容许主机间通信的具体性能。 互联网的核心思想是两台计算机能够互相通信。 只管很少发现两台主机间接相互连接的状况，但如果理解它们连贯在一起会产生什么对于理解多台主机通过交换机或路由器进行通信时产生的所有其余事件至关重要。 因而，本文将重点介绍主机到主机的通信，以及该过程中波及的每个独自步骤。 主机到主机通信因为图中没有路由器，咱们晓得所有通信都产生在同一个网络中——因而，主机 A 和主机 B 都配置了属于同一网络的 IP 地址。 每个主机都有惟一的 IP 地址和 MAC 地址。 因为每个主机也是一个 L3 设施，所以每个主机都有一个 ARP 表。 目前，他们的 ARP 表是空的。 主机 A 首先为主机 B 生成一些数据。主机 A 晓得此数据的最终目的地将是 IP 地址 10.10.10.20（主机 B）。 主机 A 也晓得它本人的地址 (10.10.10.10)，因而可能应用所需的源和指标 IP 地址创立 L3 报文头。 但正如咱们之前理解到的，数据包传递是 L2 的工作，因而只管这些主机彼此间接相连，但必须创立 L2 报文头。 L2 报文头的源MAC 地址将是主机 A 的 MAC 地址 (aaaa.aaaa.aaaa)。 L2 报文头的目标MAC 地址应该是 Host B 的 MAC 地址，但此时 Host A 在其 ARP 表中没有 Host B IP 地址的条目，因而，不晓得 Host B 的 MAC 地址。 ...

互联网是许多不同元素的迷人组合，它们独特发明了一个世界范畴的网络，容许数十亿不同的设施进行通信。在本文中，咱们将看看互联网的一些要害参与者，以及每个参与者为实现网络通信而施展的作用。 此列表远非详尽无遗，但将涵盖你须要相熟的次要“角色和工作人员”，以便理解数据包如何通过互联网传输。 主机主机这个术语是一个通用术语，示意互联网上的任何类型的终端设备。 任何可能是流量的原始发起者或流量的最终目的地的设施都能够被视为主机。 传统的例子是你的电脑或笔记本电脑。但在这个古代社会，还有很多：手机、智能电视、智能手表、某些汽车，甚至一些冰箱！ 主机运行软件和应用程序，供终端用户互动，它们在某些时候也须要把比特放在电线上。因而，也就是说主机工作在 OSI 模型的所有七层中。 在典型的互联网通信或网络流量中，通信中的两个主机通常被标记为客户端或服务器。 客户端是发动申请的实体，并心愿获取一条信息或数据或服务。 而服务器是接管申请的实体，领有客户端想要的信息、数据或服务。 应该留神的是，这些术语是绝对于特定类型的通信而言的。 例如，当你的笔记本电脑浏览网页时，你的笔记本电脑充当客户端，而 Web 服务器充当服务器。 然而，当同一个 Web 服务器随后下载软件更新时，它当初充当客户端并与更新服务器通信。 网络网络就是两个或多个连贯的设施——通常按类似的用处或物理地位组合在一起。 网络能够采纳多种不同的模式，例如： 教室里的一组 PC 都在同一个物理空间中，都属于一个网络。任何典型的家庭网络都将包含多台笔记本电脑、移动电话或打印机，它们都绑定到同一个物理地址。 因而，都属于同一个网络。有 WiFi 的咖啡店将容许他们的每个客户连贯到同一个 WiFi 网络。一家大公司可能会应用多个网络，通常按工作角色将它们离开。 例如，一个网络供所有会计师应用，另一个网络供所有工程师应用。 依据每个网络的用处，其中的设施将与同一网络中的其余设施或不同网络中的其余设施进行通信。 在本系列文章的其余部分中探讨的任何要害参与者相互连接时，你就领有了一个网络。 事实上，整个互联网只不过是一系列相互连接的网络。 交换机交换机是一种网络设备，其次要目标是用于网络内的通信。 交换机工作在 OSI 模型的 L2，这意味着它们只查看每个数据报的 L2 报文头。 L2 报文头蕴含实现一跳到另一跳传递的信息，例如源和指标 MAC 地址。 交换机通过保护所谓的 MAC 地址表来实现这项工作。 这个表映射了插入到每个交换机端口的设施的 MAC 地址。 典型的交换机有许多端口，从 24 到 48，96 个，甚至更多。 MAC 地址表是通过查看任何接管到的帧的源 MAC 地址字段来填充的。 为了转发帧，交换机将在 MAC 地址表中查找指标 MAC 地址以确定要应用的端口。 如果交换机遇到一个帧，但并不知道指标 MAC 地址的地位，它会简略地复制该帧并将其从每个交换机端口（除了接管它的端口）收回。 这个过程将在本系列的另一篇文章中更具体的探讨。 路由器路由器是一种网络设备，其次要目标是用于网络之间的通信。 路由器上的每个接口都会创立一个网络边界。 ...

开放系统互连模型（OSI 模型）解释了互联网工作所需的所有独立性能。 它是由 7 个独立的性能组合而成，实现了计算机与计算机通信的最终目标。 就像汽车是由独立的性能组成，这些性能联合起来实现了驱动汽车后退的最终目标: 电池给电子设备供电，发电机给电池充电，发动机转动主轴，轴把主轴的转动转移到车轮上，等等。 每个独立的整机都能够独立更换或者工作，只有每个独立的整机都能失常工作，汽车就能够后退。 OSI 模型分为 7 个不同的层，每一层都实现一个十分特定的性能。 当组合在一起时，每个性能都有助于实现残缺的计算机到计算机的数据通信。 在本文的其余部分，咱们将看到 OSI 模型的每个独立的层以及它们各自的职责。 OSI 第 1 层-物理层OSI 模型的物理层负责比特（bit）的传输——1 和 0 形成了所有计算机代码。 该层代表承载两个节点之间流量的物理介质。 一个例子是你的以太网电缆或串行电缆。 然而不要太在意“物理”这个词——这一层是在20世纪70年代命名的，远在网络中的无线通信概念之前。 因而，只管 WiFi 没有物理、无形的存在，但也被视为第 1 层协定。 简略地说，第 1 层是在两个节点之间携带 1 和 0 的任何货色。 “线路”上数据的理论格局可能因每种介质而异。 在以太网的状况下，比特以电脉冲的模式传输。 在 WiFi 的状况下，比特以无线电波的模式传输。 在光纤的状况下，比特以光脉冲的模式传输。 除了物理电缆，中继器（Repeater）和集线器（Hub）也在这一层运行。 中继器只是将信号从一种介质转发到另一种介质，容许一系列电缆串联在一起，并减少信号能够传输的范畴，超出单根电缆的限度。 这些通常用于大型 WiFi 部署，其中单个 WiFi 网络在多个接入点中“反复”以笼罩更大的范畴。 集线器（Hub）只是一个多端口中继器。如果四个设施连贯到一个集线器，那么一个设施发送的任何信息都会反复到另外三个设施。 OSI 第 2 层-数据链路层OSI 模型的数据链路层负责与物理层接口。 实际上，L2 负责将 1 和 0 放在电缆上，并从电缆上取出 1 和 0。 ...

本文说的零拷贝都是基于网络传输。 什么是零拷贝零拷贝并不是不须要拷贝，而是缩小不必要的拷贝次数。 传统 IO 流程通常咱们须要拜访硬盘数据的时候，用户过程须要借助内核来拜访硬盘的数据；用户通过调用零碎办法，如 read()、write()等办法告诉内核，让内核做相应的事件。 read(); 传统读取数据的流程： 在没有 DMA 之前的拷贝流程如上图所示： 用户调用 read 零碎办法CPU 收到 read 申请后，给磁盘发动一个对应的指令硬盘筹备好数据，并将数据放到缓冲区中，给 CPU 发动 IO 中断指令CPU 收到中断指令后，暂停正在做得事件，将磁盘中的数据读取到内核缓冲区中紧接着，CPU 将数据拷贝到用户缓冲区中此时，用户便可拜访数据以上流程中，波及到数据的拷贝都须要 CPU 来实现，CPU 是十分宝贵的资源，CPU 在拷贝数据的时候，无奈做其余的事件，如果传输的数据十分大，那么 CPU 始终在拷贝数据，无奈执行其余工作，代价十分大。 DMA实质上，DMA 技术就是计算机主板上一块独立的芯片，当计算机须要在内存和 I/O 设施进行数据传输的时候，不再须要 CPU 来执行耗时的 IO 操作，而是通过 DMA 控制器来实现，流程如下。 上图可知，数据拷贝由 DMA 实现，CPU 不须要在执行一些耗时的 IO 操作。 下图能够更形象的表白文件传输的过程： 步骤阐明如下： 用户过程调用零碎函数 read()内核接管到对应指令之后去磁盘将文件读取到内核缓冲区中，数据筹备好之后发动一个 IO 中断CPU 收到 IO 中断信号之后进行手中的工作，将内核缓冲区中的数据拷贝到用户过程中用户过程收到数据之后调用零碎函数 write()，由 CPU 将数据拷贝到 socket 缓冲区中由 DMA 控制器将 socket 缓冲区中的数据拷贝到网卡中，进行数据传输。以上传统的 IO 数据拷贝在性能上有很大的晋升空间， 由上图看出，在文件传输的案例中，咱们将数据拷贝到用户数据缓冲区，用户过程没有通过任何数据处理，将文件间接发送进来。因而，这一个步骤是多余的，能够省略。 ...

https://blog.csdn.net/zzhongc...

如图：想要挪动终端10.7.7.3能拜访192.168.10.3两台爱快要如何设置？当初挪动终端10.7.73能拜访192.168.10.1，但不能拜访192.168.10.3因物理地位主观限度，四个网段会客观存在。目标是192.168.10、20、30及10.7.7这四个网段能相互拜访。谢谢！

计算机网络体系结构分为3种：OSI体系结构（七层），TCP/IP体系结构（四层），五层体系结构。 1.OSI 体系结构：概念分明理念残缺，但简单不实用；2.TCP/IP 体系结构：含了一系列形成互联网根底的网络协议，是Internet的外围协定，被广泛应用于局域网和广域网；3.五层体系结构：交融了OSI 与 TCP/IP的体系结构，目标是为了学习解说计算机原理。 TCP/IP与OSI最大的不同在于：OSI是一个实践上的网络通信模型，而TCP/IP则是理论运行的网络协议。本文重点介绍TCP/IP体系。 档次名称单   位功    能协    议网络接口（Host-to-Net Layer）帧负责理论数据的传输，对应OSI参考模型的下两层HDLC（高级链路控制协议）PPP（点对点协定）SLIP（串行线路接口协议）网络层（Inter-network Layer）数据报负责网络间的寻址数据传输，对应OSI参考模型的第三层IP（网际协议）ICMP（网际管制音讯协定）ARP（地址解析协定）RARP（反向地址解析协定）传输层（Transport Layer）报文段负责提供牢靠的传输服务，对应OSI参考模型的第四层TCP（控制传输协定）UDP（用户数据报协定）应用层（Application Layer） 负责实现所有与应用程序相干的性能，对应OSI参考模型的上三层FTP（文件传输协定）HTTP（超文本传输协定）DNS（域名服务器协定）SMTP（简略邮件传输协定）NFS（网络文件系统协定）

一. 网络体系结构的基本概念1、什么是网络协议 在生活中，咱们多于通信协议并不生疏，一种语言自身就是一种协定。在咱们寄信或者销假时，假条内容的格局就是一种协定。这样的例子很多。在计算机中，计算机网络由多台主机组成，主机之间须要一直的替换数据。要做到井井有条的替换数据，就须要肯定的或者实现约定好的通信规定。 为网络数据交换制订的通信规定，咱们称为网络协议（protocol）。 2、层次结构 档次（Layer）构造是解决计算机网络问题的最根本的办法，对于一些简单的问题，咱们常常采纳“化整为零，分而治之”的思维，将一个简单的问题合成为若个小问题去解决。 3、接口 （1）同一主机的相邻层之间存在着明确的接口，相邻层之间通过接口来传递信息。 （2）低层通过接口向高层提供服务。只有接口不变，低层协定不变，实现低层协定的技术变动不会影响整个零碎的工作。 国产接口测试和接口文档生产工具：apipost 4、网络体系结构 （1）网络体系结构是网络层次结构和各层协定之间的汇合。 （2）网络体系结构对计算机网络实现的性能应该准确定义。 （3）网络体系结构是形象的，而实现网络协议的技术是具体的。 二、OSI七层模型OSI七层协定模型次要是：应用层（Application）、表示层（Presentation）、会话层（Session）、传输层（Transport）、网络层（Network）、数据链路层（Data Link）、物理层（Physical）。 1、物理层：比特 次要定义物理设施规范，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的次要作用是传输比特流（就是由1、0转化为电流强弱来进行传输,达到目的地后在转化为1、0，也就是咱们常说的数模转换与模数转换）。这一层的数据叫做比特。 2、数据链路层：帧 定义了如何让格式化数据以进行传输，以及如何让管制对物理介质的拜访。这一层通常还提供谬误检测和纠正，以确保数据的牢靠传输。 3、网络层：数据报 在位于不同地理位置的网络中的两个主机零碎之间提供连贯和门路抉择。Internet的倒退使得从世界各站点访问信息的用户数大大增加，而网络层正是治理这种连贯的层。 4、运输层：报文段/用户数据报 定义了一些传输数据的协定和端口号（WWW端口80等），如：TCP（transmission control protocol –传输控制协议，传输效率低，可靠性强，用于传输可靠性要求高，数据量大的数据）UDP（user datagram protocol–用户数据报协定，与TCP个性恰恰相反，用于传输可靠性要求不高，数据量小的数据，如QQ聊天数据就是通过这种形式传输的）。 次要是将从上层接管的数据进行分段和传输，达到目标地址后再进行重组。经常把这一层数据叫做段。 5、会话层： 通过运输层（端口号：传输端口与接管端口）建设数据传输的通路。次要在你的零碎之间发动会话或者承受会话申请（设施之间须要相互意识能够是IP也能够是MAC或者是主机名） 6、表示层： 可确保一个零碎的应用层所发送的信息能够被另一个零碎的应用层读取。例如，PC程序与另一台计算机进行通信，其中一台计算机应用扩大二一十进制替换码（EBCDIC），而另一台则应用美国信息替换规范码（ASCII）来示意雷同的字符。如有必要，表示层会通过应用一种通格局来实现多种数据格式之间的转换。 7.应用层：报文 三、五层体系结构1 第五层——应用层(application layer) 应用层(application layer)：是体系结构中的最高。间接为用户的利用过程（例如电子邮件、文件传输和终端仿真）提供服务。 在因特网中的应用层协定很多，如反对万维网利用的HTTP协定，反对电子邮件的SMTP协定，反对文件传送的FTP协定，DNS，POP3，SNMP，Telnet等等。 2. 第四层——运输层(transport layer) 运输层(transport layer)：负责向两个主机中过程之间的通信提供服务。因为一个主机可同时运行多个过程，因而运输层有复用和分用的性能 复用，就是多个应用层过程可同时应用上面运输层的服务。 分用，就是把收到的信息别离交付给下面应用层中相应的过程。 运输层次要应用以下两种协定： (1) 传输控制协议TCP(Transmission Control Protocol)：面向连贯的，数据传输的单位是报文段，可能提供牢靠的交付。 (2) 用户数据包协定UDP(User Datagram Protocol)：无连贯的，数据传输的单位是用户数据报，不保障提供牢靠的交付，只能提供“尽最大致力交付”。 3. 第三层——网络层(network layer) 网络层(network layer)次要包含以下两个工作： (1) 负责为分组替换网上的不同主机提供通信服务。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组或包进行传送。在TCP/IP体系中，因为网络层应用IP协定，因而分组也叫做IP数据报，或简称为数据报。 (2) 选中适合的路由，使源主机运输层所传下来的分组，可能通过网络中的路由器找到目标主机。 ...

说到计算机网络原理，大家可能马上联想到，七层协定，传输层，链路层，三次握手四次挥手；前端的同学，还会想到咱们用Crome F12的network外面的headers，状态码等。后端同学可能会联想到，抓包，路由网关等。你们联想到什么关键字，欢送留言哟！ 那么，咱们来提出几个问题： 七层协定之间是如何传输的？什么是包、帧、段？TCP/IP协定是什么？TCP和UPD有什么区别？什么是三次握手四次挥手？为什么要握手和挥手？浏览器network的HTTP headers 和 TCP headers有什么区别？上面，咱们就一一答复下面的问题。 七层协定之间是如何传输的？什么是包、帧、段？ 看上图，所以数据、段、包、帧、比特，讲的其实都是一个货色，只是因为所在的地位不同，作为专有名词的名字不同。 咱们先看一下最上层的数据，Data是应用层协定产生的数据，例如拜访网页、看视频、听音乐，这些都能够称为应用层数据，电脑的操作系统会把这些应用层数据依照肯定的规定传给下一层传输层。在传输层，咱们看到的数据称之为Segment，中文意思是段。在这一层，数据会被加上TCP或者UDP头，变成一个应用程序特有的数据。操作系统就是通过TCP或UDP端口号来区别不同应用程序的。当数据再被往下传输的时候，就变成了packet，即“包”的意思。在这一层，Segment会被加上IP头部信息，而后就能够在三层传输了，而工作在三层的路由器会依据目标IP地址来转发这些”包“。在往下，数据就会被加上MAC地址信息，名称就变成了Frame，”帧“。在这一层，就是交换机的世界了，交换机通常查找MAC地址表项来转发相应的”帧“。下面的几个档次都能够应用wireshark抓包查看到具体的内容，比拟形象，例如上面，一层套着一层，显著能够看出帧、包、段、数据的区别。 那么，不同层之间，是如何通信的呢？ 很多人讲到七层协定传输，会想到教材下图左，可是这七层是如何一层层相互形成的，更合乎大脑感官的是另一种认知模式，是一种洋葱形的构造，层层叠叠相互包裹，能够用下图示意： 一层一层传输，加上图一对应的头部信息，或者mac地址，进行封装，传给下一层。具体的也能够看上图抓包信息。每一层的数据，内容不同，叫不同的名字。 再往下面的物理层（layer1），咱们能看到的都是BIT流，它们出现给咱们的都是0和1这样的电气个性。他们将数字信号转化为物理信号，bits 转化为光信号。网络延时，个别在这一层，思考传输间隔和光速，光纤管道拥塞，包期待，TCP 做 Flow Control（流控），转化速率等，平时只有那些头发比拟稀少的硬件工程师才关注，咱们个别看不到。工作中咱们看到网络设备的物理层都曾经是十分成熟的内容，个别不会有问题。 各位看到这里，应该可能明确“帧”和“包"区别了吧？其实很多的时候它们就是通用的，只是它们所在的网络档次不同，封装也不同。为了显示业余，个别咱们在探讨交换机相干的layer2内容时，能够把数据称之为”帧“，在探讨与路由器相干的layer3内容时，就把数据称之为”包“。他们是如何传输的，以上也做了解答。 TCP/IP协定是什么？TCP和UPD有什么区别？计算机硬件通过网络通信，单方就要基于雷同的办法。比方，如何探测到通信指标、由哪一边先发动通信、应用哪种语言进行通信、怎么完结通信等规定都须要当时确定。不同的硬件、操作系统之间的通信，所有的这所有都须要一种规定。而咱们就把这种规定称为协定（protocol）。 TCP/IP 是互联网相干的各类协定族的总称，比方：TCP，UDP，IP，FTP，HTTP，ICMP，SMTP 等都属于 TCP/IP 族内的协定。TCP/IP模型是互联网的根底，它是一系列网络协议的总称。这些协定能够划分为四层，别离为链路层、网络层、传输层和应用层。 也就是每一层都有本人的协定，咱们前端在浏览器调试的是HTTP协定，属于TCP/IP协定的一种。具体看下图： 应用层：负责向用户提供应用程序，比方HTTP、FTP、Telnet、DNS、SMTP等。传输层：负责对报文进行分组和重组，并以TCP或UDP协定格局封装报文。网络层：负责路由以及把分组报文发送给指标网络或主机。链路层：负责封装和解封装IP报文，发送和承受ARP/RARP报文等。咱们前端接触的比拟多的，就是应用层和传输层协定。 传输层协定外面有UDP和TCP协定，咱们来看看他们具体区别和利用场景。 UDP和TCP协定区别 如上图： TCP向下层提供面向连贯的牢靠服务 ，UDP向下层提供无连贯不牢靠服务。尽管 UDP 并没有 TCP 传输来的精确，然而也能在很多实时性要求高的中央有所作为 对数据准确性要求高，速度能够绝对较慢的，能够选用TCP 咱们在第一局部，阐明了，从应用层到传输层，会加上UDP/TCP头，那什么状况加UDP头，什么状况加UDP头呢？以下别离进行阐明： UDPUDP协定全称是用户数据报协定，在网络中它与TCP协定一样用于解决数据包，是一种无连贯的协定UDP有不提供数据包分组、组装和不能对数据包进行排序的毛病，也就是说，当报文发送之后，是无奈得悉其是否平安残缺达到的。 它有以下几个特点： 面向无连贯首先 UDP 是不须要和 TCP一样在发送数据前进行三次握手建设连贯的，想发数据就能够开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。 具体来说就是：在发送端，应用层将数据传递给传输层的 UDP 协定，UDP 只会给数据减少一个 UDP 头标识下是 UDP 协定，而后就传递给网络层了。在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作。 有单播，多播，播送的性能UDP 不止反对一对一的传输方式，同样反对一对多，多对多，多对一的形式，也就是说 UDP 提供了单播，多播，播送的性能。 UDP是面向报文的发送方的UDP对应用程序交下来的报文，在增加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因而，应用程序必须抉择适合大小的报文。 不可靠性首先不可靠性体现在无连贯上，通信都不须要建设连贯，想发就发，这样的状况必定不牢靠。 并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关怀对方是否曾经正确接管到数据了。 ...

MSL 是 Maximum Segment Lifetime，报文最大生存工夫，它是任何报文在网络上存在的最长工夫，超过这个工夫报文将被抛弃。因为 TCP 报文基于是 IP 协定的，而 IP 头中有一个 TTL 字段，是 IP 数据报能够通过的最大路由数，每通过一个解决他的路由器此值就减 1，当此值为 0 则数据报将被抛弃，同时发送 ICMP 报文告诉源主机。 MSL 与 TTL 的区别：MSL 的单位是工夫，而 TTL 是通过路由跳数。所以 MSL 应该要大于等于 TTL 耗费为 0 的工夫，以确保报文已被天然沦亡。 TIME_WAIT 期待 2 倍的 MSL，比拟正当的解释是：网络中可能存在来自发送方的数据包，当这些发送方的数据包被接管方解决后又会向对方发送响应，所以一来一回须要期待 2 倍的工夫。 比方如果被动敞开方没有收到断开连接的最初的 ACK 报文，就会触发超时重发 Fin 报文，另一方接管到 FIN 后，会重发 ACK 给被动敞开方， 一来一去正好 2 个 MSL。 2MSL 的工夫是从客户端接管到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 工夫内，因为客户端的 ACK 没有传输到服务端，客户端又接管到了服务端重发的 FIN 报文，那么 2MSL 工夫将从新计时。 ...

置信大家对网络直播曾经不再生疏了。 2016年被称为直播元年，根底技术逐步成熟，引出千播大战。在红海下，纯正的直播逐步失去竞争力，不少企业开始走内容垂直化，跟秀场、游戏、电商、广电等内容特点深度联合。其中内容垂直化最为胜利的，莫过于电商直播。据一些行业调查报告，2020年中国电商直播市场规模靠近万亿元，年增长超过100%，增长势头强劲。2020年S1疫情暴发，电商为病毒隔离奉献微小，同时疫情也为电商直播购物按下了减速键。 电商体系中，多媒体传输网络处于要害地位，承载着内容中台的基座。 电商内容体系架构图 电商体系中，内容中台为次要增长引擎。2020年淘宝双十一GMV达到4982亿，淘宝直播带宽峰值超过7T，比去年增长超过1倍。直播玩法、用户体验、零碎稳定性都比去年大幅晋升，GRTN（Global Realtime Transport Network）新一代多媒体传输网络为双十一的增长保驾护航，整个双十一期间，零碎如丝般顺滑。 （淘宝直播专题内容正在更新，欢送关注【淘系技术】公众号）GRTN新一代多媒体传输网络架构多媒体传输网络，是不是就是CDN？答案当然是否定的，CDN只是传输网络的一部分。多媒体传输网络包含内容生产、编解码、内容散发、观看体验、宏观控制。GRTN是一套从生产到生产，从性能到管控的残缺的零碎。 GRTN新一代多媒体传输网络架构 内容生产：让直播更好玩淘宝直播走到当初曾经5个年头，主播的能力有了很大进步，咱们的权利互动也做了很多翻新，往年咱们更重视直播的内容，咱们心愿主播在直播卖货的同时，也能产生很多很乏味的内容，让大家买买买的同时，放弃好情绪。所以咱们重点做了直播游戏互动玩法，使得直播在卖货的同时也能更加乏味好玩。 内容生产流内互动的零碎次要分为3个局部：功能强大的素材玩法编辑器、灵便通用的脚本编辑器、跨平台渲染计算引擎。编辑器是内容生产的用户界面，提供各种素材、玩法的编辑能力。然而，有时简略的素材和玩法不能满足需要，须要用一套脚本来管制素材和玩法的运行，为了升高脚本开发难度，脚本必须灵便通用。最初所有的素材、玩法要在流外面展示进去，必须依附渲染计算引擎。 编解码：老本更低，体验更好S265是直播老本极佳的编解码计划带宽是直播经营中最大的老本，依据前瞻网估算算全行业2020年的CDN费用收入将超过300亿元，在2025年靠近1000亿规模（https://bg.qianzhan.com/trends/detail/506/200715-ec767b9b.html），在保障视频品质的前提下升高带宽是老本管制中至关重要的一环。 相机采集到的视频数字信号通常是yuv格局，每个像素点须要1.5个Byte来示意，以720p 25fps为例，带宽有263.67Mbps，直播1小时总流量有124.4GB，如有100万人观看这场直播，CDN费用高达1.58亿。好在视频图像外部帧与帧之间存在十分高的相关性，采纳视频压缩技术去除相关性后，能够将带宽升高到原来的100-400倍； 视频压缩规范次要有ISO（国际标准组织）制订的MPEG系列和ITU（国际电信联盟）主导的H.26X系列，2003年两大组织组成联结专家组（JVT），独特制订了AVC(H.264)编码标准，2013年JVT公布了HEVC(H.265)规范，HEVC 作为比AVC更新一代的视频压缩规范，雷同画质下能够节俭一半码率. S265是基于H.265规范实现的软编码器，具备高压缩、高效率、适应场景广三大特点，比照业界开源的X265可节约20%以上的码率且编码速度晋升100%-600%；目前已在淘宝直播、优酷视频、阿里云MTS、VMate、钉钉会议等业务中上线应用； S265的优化思路蕴含两个方面，一方面从码率管制、编码工具两个方向优化编码品质，另一方面从疾速算法及工程优化两方面优化编码速度，下表能够看到，S265相比X265和X264都有更高的码率劣势或速度劣势； 上面是一个demo视频，右边是S265的压缩后果，左边是X265的压缩后果。能够看到，等同码率下S265的高空瓷砖的纹理及水纹更清晰（语雀有二次压缩，原片更显著） output.mp4 右边S265，左边X265 从另一个角度看，雷同品质下，S265的码率能够大幅节俭，从而升高带宽老本。下图左侧是X264的压缩2400kbps，右侧是S265 1200kbps的后果，码率相差一倍，S265的品质还更好。 45_x264_ali265.mp4 过来一年，淘宝直播的在线规模减少超过一倍，而CDN的带宽老本简直未减少，这还是在FY20相比FY19曾经升高一倍的前提下产生，S265起到了至关重要的作用。 S265降低成本前提下不降体验尽管S265大幅升高了直播老本，但体验并未升高。 在清晰度方面，淘宝直播S265 在720p分辨率下的均匀推流码率在 800kbs以下，但大盘监控的均匀psnr大于42db。在往年双十一还上线了1080p高清直播，满足用户极致高清的需要。 在流量管制方面，S265反对秒级码率调控，能够让GRTN流量调度在1秒内实现对大盘流量的管制，实现CDN流量的全面掌控； 在编码延时方面，S265实现了低延时压缩模式，相比X265 Medium模式升高了70%的编码延，且编码品质简直不损失。 最初，随同着码率升高，网络传输的压力也相应降落，用户体验的卡顿率和秒开指标都有显著晋升，过来一年淘宝直播的卡顿vv降落了25%，秒开率绝对值晋升了1%，跟码率降落有间接的关系。 内容散发：二网合一的传输零碎在流媒体畛域，提到直播技术，往往会想到RTMP、HTTP-FLV、QUIC-FLV、SRT，只有提到连麦、通话、视频会议，才会想到RTC(webrtc)。现在淘宝直播架构整体降级，一改来日印象，将直播全链路跑在了RTC之上，实现了直播网和通信网的交融，实现了二网合一。 对立架构后，实时音视频通话和直播两大业务，应用对立套代码，一套运维体系，缩小保护老本。同时，淘宝直播针对业务特点，对交融网络架构进行了深度定制，自研了适宜直播业务的拥塞控制算法和网络传输策略。针对 WebRTC 中网络传输的外围，淘宝直播对拥塞控制算法的摸索层层深刻。从基于特定网络场景的深度定制优化，到系统性的参数探测优化，再到基于神经网络的拥塞控制算法相干的前沿摸索，深度定制的优化落地，使得推流端卡顿总体降落 40% ，提早也降落了 12%，主播推流更加平滑稳固；前沿摸索的学术后果，也曾经两次由网络方向国内顶级会议 MobiCom 接管和发表。 低提早传输是一个综合性问题，对于直播来说要兼顾老本，体验，提早，须要客户端，服务器配合，基于线上数据一直迭代。相干控制算法从webrtc残缺模块化剥离和重构，性能是webrtc原来实现的2倍以上，针对直播大的I帧场景深度定制优化，同时兼顾秒开和提早，谋求最大吞吐率。在网络小范畴抖动状况下不受影响，最大反对20%丢包和500ms内的抖动。绝对于去年同期指标，卡顿率升高79%，卡顿VV升高44%，秒开率晋升32%，提早和首帧达到工夫升高100多ms。 淘宝直播与其余直播利用比照 通过用秒表内容推流，拍摄推流和播放内容的形式，测得端到端延时，手淘根本在2秒以下，而行业内大部分直播软件还是FLV技术，延时通常在5秒以上。通过严格的AB测试证实，端到端延时升高，对促成GMV有侧面成果。网络好时，比照卡顿没有意义，大家卡顿率都为0，因而通过网损仪减少30%丢包、100ms延时测试，卡顿状况就不一样了，因为RTC有拥塞管制、网络抗丢包策略，30%丢包齐全无卡顿，而FLV直播则有较高的卡顿率。 后续会持续在对立的直播通信网上优化，一直进步淘宝直播的用户体验，敬请期待。 观看体验：实在还原现场阿里团体CTO程立分享了他购买古琴的经验，买古琴不能通过惯例的图文形容来分辨古琴的好坏，卖家将程立疏导到直播间，通过主播解说，在直播间听声音来分辨古琴好坏。买到琴后发现琴的声音跟直播间里听到的齐全一样，CTO对淘宝乐器直播间的音质大加赞叹，这种所见即所得的感觉是直播最大的劣势。 “让画面更清晰，让声音更实在”，是淘宝直播的极致谋求。淘宝直播通过自研3A、智能降噪、高音质模式、窄带高清等技术，克服生产设施、观看设施及网络条件多样性适配艰难，为主播提供低成本直播计划，为观众打造高清音视频体验。 音乐直播间高保真体验： 音乐直播间.mp3 电商直播中，解说声音的清晰度间接影响沟通效率，因而要尽量屏蔽烦扰声音，降噪能力至关重要，淘宝直播团队在智能降噪上深入研究，在技术上翻新，比传统技术降噪能力更强，降噪后声音可懂度更高。 降噪前原始语音： 原始语音.mp3 通过AliDenoise智能降噪后的语音： AliDenoise语音.mp3 在画质上，淘宝直播团队通过去抖、降噪、超分等技术，实现画质加强。并且借助S265编码器高压缩率的劣势，咱们以业界720p的码率实现了1080P分辨率的高清直播。 720p_1080p.mp4 右边720P，左边1080P 宏观控制：大象也能跳舞无论怎么设计，零碎的复杂度都会逐步减少，变成一头臃肿的大象。个别的零碎，牵一发而动全身，平时已不敢随便变动，更何况大促等关键时刻。然而淘宝直播往年打造了宏观控制系统，让这头大象灵便起来，数据系统如同大象的眼镜、智能策略零碎如同大象的大脑、工作执行零碎如同大象的四肢，而业务策略配置零碎如同驯兽师手里的指挥棍。 宏观控制系统将简单零碎闭环，使得整个零碎能观能控，加强了零碎的鲁棒性。宏观控制系统的输出是以后主播的编码码率和直播成果等；基于blink搭建的多数据源自纠错的实时数据平台作为检测环节将以后的在线主播数、在线观众数、CDN带宽、以及预测的接下来一段时间内的各个数据荡涤统计后输出至决策零碎；决策零碎交融了限峰策略、工夫策略和大主播策略等多种策略，联合数据平台的反馈数据作出最优决策后告诉执行模块进行调控；基于团体多维音讯群发中间件MASS与长连通道ACCS实现的执行模块会实时调控主播的编码码率、观众观看的清晰度等，实现进步带宽利用率、进步用户体验、降低成本、确保稳固的目标;客户端编码器反对实时动静调整编码码率和智能码控档位，反对帧级实时调控，码率调控秒级失效。宏观控制系统让资源管控更加弹性，在咱们无奈精确预感将来时，申请资源以及筹备资源是一个大难题，有了宏观控制系统状况后，不必为资源预估不准而犯愁，宏观控制系统能够依据实时数据进行预测并且弹性地调整人均耗费的资源。 ...

TCP牢靠在哪？    家喻户晓，TCP是一个面向连贯的、基于流的、端到端的、牢靠数据传输协定。那么，TCP到底是如何确保数据传输的可靠性呢？     留神：牢靠传输不意味着数据安全，数据在传输中仍有被篡改数据并批改checksum的可能！ checksum    checksum由发送方计算，接管方用其来测验数据是否残缺。把伪首部(IP头局部)、TCP包头，TCP数据分为16位的字，如果总长度为奇数个字节，则在其最初补充一个值都为0的字节。在TCP报头中把校验和字段置为0，用反码相加法累加所有的字，最初取反作为TCP校验和。     留神：checksum是不可逆的操作，所以，如果接管方验证checksum失败，则数据包肯定不牢靠，然而如果接管方验证checksum胜利，数据包也不肯定就是牢靠的。 确认应答与序列号    TCP协定将数据给每个字节都调配一个惟一的、递增的序列号(sequence number 16 bit)，这个机制十分重要，接管方能够通过序列号进行去重，拒绝接受反复数据。确认应答机制是指接管方收到TCP包之后，会向发送方回传一个带有ACK标记位的TCP包，通知发送方本人收到了哪些数据。 超时重传    TCP每发送一部分数据之后都要承受ACK包以确认是否发送胜利。那么在这个交互的过程中，如果发送方没有接管到ACK是否要始终阻塞上来呢？没有收到ACK包可能是在发送数据的过程中数据包失落了，也有可能是在返回的过程中ACK包失落了。这个时候TCP的超时重传机制发挥作用，在期待一个最大超时工夫之后，TCP将从新发送方才失落的数据包，如果该数据包是因为第一个起因失落的，则接管方从新承受，若胜利就返回ACK，若数据包失落的违心是第二种，则接管方利用sequence number去重，丢掉该数据包，间接返回ACK。那具体要期待多长时间之后进行超时重传呢？一般来讲操作系统会有一个初始值，而后会以初始值的x次方作为最大超时工夫，x示意以后重传次数。累计达到肯定的重传次数，操作系统就会认为网络情况太差，强行中断连贯。 连贯治理    艰深的讲，连贯治理就是咱们耳熟能详的三次握手和四次挥手。     置信这种讲TCP握手的图，大家没少见。这里就不细说了，次要讲为什么须要三次，第三次存在的必要。举个很简略的例子，如果女神给你发消息，国际标准，一句“在吗？”，你非常高兴，回她一句“我在！”。这个时候问题呈现了，如果她就此不发消息，你是否会狐疑可能因为网络情况她基本就没收到你的回复。这就是问题的要害，第三次握手就是对确认的确认，让接管方也“心安”。     再来看四次挥手，同样具体步骤其实非常简单，那么为什么挥手须要四次呢？其实情理也非常简单，当服务器收到客户端的FIN之后，只能阐明什么？阐明客户端想走。然而服务器想不想让它走呢？这得取决于服务有没有实现，如果缓冲区中还有数据，那么要不要发呢？答案是必定的。所以客户端是想走就走，可服务器做事稳重，须要思考很多货色，等解决欠缺了，才想客户端发送FIN。实现挥手。 流量管制    事实中网络受很多因素烦扰，不同的网卡，不同的网络环境，都可能会影响到网速。而接管方与发送方之间带宽的不匹配是一个很大的问题，如果发送方带宽很大，接管方来不及收怎么办？这就引入了滑动窗口协定。接管方在承受完一个TCP包之后，所返回的ACK报文中会携带滑动窗口的大小，这个大小个别是接管方缓冲区的残余大小。发送方发送数据包之前会先发一个窗口探测的包。依据对方窗口余量进行数据放松，做到单方带宽匹配。为了防止流量管制引发的死锁，TCP应用了继续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。工夫一到便被动发送报文询问接收者的窗口大小。若接收者依然返回零窗口，则重置该计时器持续期待；若窗口不为0，则示意应答报文失落了，此时重置发送窗口后开始发送，这样就防止了死锁的产生。 拥塞管制    TCP为了在传输中防止网络拥挤，采取了一种试探的技术，以比拟智能的办法躲避拥挤，这就是拥塞管制的伎俩。在刚开始发送的时候将发送窗口定义为1，拥塞窗口为1意味着以后每发送1个包就须要收到应答，之后每收到一次ACK，就将这个值乘2，每超时重传一次就将这个值减半，这就是所谓的“慢开始”。拥塞管制还引入“快重传”的概念以进步吞吐量。快重传要求接管方在收到一个失序的报文段后就立刻收回反复确认。快重传算法规定，发送方只有一连收到三个反复确认就该当立刻重传对方尚未收到的报文，而不用持续期待设置的重传计时器工夫到期。

文章内容概览 在之前的文章中有理解到跨设施传输时，须要借助路由表来晓得数据报下一跳的IP 在路由表中有两列重要的信息，别离是：目标IP地址和下一跳IP地址，这两个IP造成映射的关系。在前边理解数据报转发时，都是间接应用的路由表，这样就会存在几个疑难 路由表中的下一跳地址是怎么来的？ 下一跳地址是惟一的吗？ 下一跳的地址是最佳的吗？ 路由器这么多，他们之间是怎么协调工作的？ 这些问题就是网络层路由须要解决的问题，其实也就是须要一个好的算法去解决这些问题。所以，理解网络层的路由就是理解里边的一些算法 在前边的文章中屡次用到的一个网络拓扑，在这个拓扑中有计算机、路由器、小型网络、中型网络、大型网络 这个图其实就是现实生活中互联网的缩略图，它能够主观的形容事实世界中的互联网。然而，在学习其中的算法时，这个图并不能直观的表白咱们所须要解决的问题，因而，在理解里边的算法时，就把它转化成计算机容易了解的数据结构，所以，这个网络拓扑，通常会将这个网络拓扑转化为图来进行形容 下边这张图是一个简略的网络拓扑转化而来的，其中有A、B、C、D、E、F这六个顶点和若干条边。每个顶点示意一个网络或路由器或计算机。每一条边示意一条网络门路。比方从A到E就有很多条门路能够走，在事实网络中也是这样的。所以，该图就能够十分主观的示意现实生活中的网络 如果把互联网形象成一张图的话，那么，路由算法实际上就是图论算法。然而，路由算法又不仅仅是图论算法，因为互联网是非常复杂的，比方，网络常常产生抖动，或网络呈现故障。这就会导致图会实时的变动。因而，路由算法，实际上要比图论算法简单很多 一个现实的路由算法有以下特点： 算法是正确的、残缺的（也就是说，根据该算法，数据能够正确的、残缺的达到目的地）算法在计算上应该尽可能的简略（因为网络中的设施切实太多，因而互联网是非常复杂的且宏大的。如果在宏大的互联网中运行简单的算法的话，是不可取的）算法能够适应网络中的变动（因为网络中的状态是实时发生变化的，比方在某一刻，一个路由器产生了故障，或者光纤或电缆断了）算法是稳固和偏心的（稳固就是，即便一个设施呈现故障，也不会影响到别的网络或设施。偏心就是，算法对每一个设施(计算机、路由)都是偏心的，不会因为设施的不一样，而导致转发的门路不一样）在前边提到了： 互联网的规模是宏大的互联网环境是非常复杂的因而为了让路由算法简略一些，也人为的对互联网进行了解决。对互联网进行了划分，这其中就蕴含一个十分重要的概念：自治零碎（Autonomous System，简称AS） 一个自治零碎（AS）是处于一个管理机构下的网络设备群（管理机构：能够是一个国家、一个城市、一个公司）AS外部网络自行治理，AS对外提供一个或多个出入口（AS内部的设施不直接参与外部的治理，如果外部设备须要对AS进行拜访的话，通过AS提供的一个或多个出入口进行拜访）在之前的文章中有对网络档次进行了如下的划分 理解了AS之后，就能够晓得，其实每一个骨干ISP，都能够了解成骨干AS，每个地区ISP，都能够了解成地区AS。理解了自治零碎AS的概念之后，就能够把路由算法分为两个档次： 运行在自治零碎外部路由的协定称为：外部网关协定（RIP、OSPE）运行在自治零碎内部路由的协定称为：内部网关协定（BGP）能够通过一个图示了解外部网关协定和内部网关协定 假如有一个AS1（可能是一个公司的网络），有一个AS2（可能是一个学校的网络），当一个公司和一个学校进行互相拜访时，他可能就是通过内部网关协定进行路由的 在疾速变动的技术中寻找不变，才是一个技术人的外围竞争力。知行合一，实践联合实际

文章内容概览 ICMP协定详解网际管制报文协定（Internet Control Message Protocol）该协定次要是用于辅助IP协定进行数据传输的ICMP协定能够报告错误信息或者异常情况ICMP的报文数据是通过封装在IP数据报中进行数据传输的。ICMP的报文分为两个局部：ICMP报文首部和ICMP报文数据 ICMP报文首部 类型：次要指的是ICMP报文的品种(次要有两大类，后边会进行阐明)代码：次要是指，不同的ICMP报文品种具体有哪些谬误校验和：次要是校验报文在整个传输中，是否存在谬误在前边介绍IP协定首部中，有一个8位协定，它表明的是IP数据所携带的具体数据是什么协定的。ICMP的字段值为1 如果IP协定传输的数据是ICMP数据的话，那么，将会在协定中写入1 ICMP协定报文的两个品种过错报告报文 网络不可达：IP地址能够示意一个网络，当主机号全为0时就示意的是某一个网络，如果整个网络不可达，就会报告一个类型为3，具体代码为0的ICMP协定报文主机不可达：如果计算机A要和计算机B进行通信，而计算机B是关机的状态，就会呈现主机不可达的状况网络重定向：传输给某一个网络的数据，可能不能走该网络了，须要进行重定向主机重定向：如果发送的报文，主机告知不能解决，请发送到另外一个主机询问报文 回送申请或应答：次要是验证网络是否通。假如计算机A要和计算机B进行通信，A会发送一个空的数据给B，如果B收到，就给一个回应工夫戳申请或应答：当须要进行工夫同步时，会用到这个ICMP协定的利用Ping利用在前边的文章中有应用到ping命令来查看网络的响应工夫和TTL。这部分次要是介绍ping的原理是什么 ping利用次要是应用ICMP的询问报文，它会发送回送申请或应答类型的报文。当应用ping命令的时候，它首先会组装一个IP协定的报文，而后在IP的数据报中组装ICMP的询问报文，而后通过数据链路层发送进来，这个就是ping利用的原理 通常咱们会应用ping命令来查看本地的网络是否通，或者网络品质是怎么样的。平时在家中，如何呈现网络故障，咱们也会应用ping命令来进行排查 第一步会先ping本地回环地址127.0.0.1（如果没有返回，阐明协定栈有问题，这个时候可能须要重装系统，或重新安装协定栈）如果上一步失常返回，则ping网关地址（也就是路由器地址）。如果计算机是处于内网的话，个别就是ping 192.168.0.1或者ping 192.168.1.1。如果上一步ping网关也是通的，阐明本机到路由器是通的，如果不通，阐明网线或者wifi是有问题的如果ping网关是通的，则ping远端地址（比方百度）。如果不通，则阐明在你家到ISP之间网络是故障的，这个时候就须要分割电信或挪动或联通Traceroute利用Traceroute能够探测IP数据报在网络中走的门路，在IP协定详解这篇文章中，有介绍到计算机是连贯在虚构互联网络中的，咱们并不关怀数据报在网络中通过了哪些门路。然而，如果须要对网络故障进行排查的话，Traceroute利用能够提供更高级的性能，使咱们更理解网络是怎么样的 Traceroute利用原理在前边介绍IP首部时，首部里边有一个TTL，表明IP数据报文在网络中的寿命，每通过一个设施，TTL减1，当TTL为0时，网络设备必须抛弃该报文 当TTL为0时，网络设备必须抛弃该报文。然而，并没有通知抛弃的时候应该怎么解决。理解了ICMP报文之后能够晓得，如果网络设备要抛弃报文，将会发送一个ICMP起点不可达过错报文。也就是说，它会报告一个谬误，通知源端主机，报文传输产生了谬误，这样源主机才会察觉到问题。下边是一个例子 借助前边用到的一个图，该图批示了从计算机A到计算机B的网络走向，前边的文章中提到，数据报文是一跳一跳的传输的，因而它会先后跳到中型网络=》大型网络=》中型网络=》小型网络=》计算机B。 Traceroute利用奇妙的利用了ICMP过错不可达报文的作用，为了探测数据报走过的门路，它首先会封装一个TTL为1的IP报文。在上图中，计算机A发送了一个TTL为1的报文之后，达到中型网络之后就会发现TTL为0了，此时就会往源机器(也就是A)收回一个ICMP过错不可达报文。此时，计算机A会记录该中型网络的IP。此时Traceroute会再封装一个TTL为2的申请报文，当数据达到大型网络之后，TTL为0了。大型网络会抛弃该报文，并且向源机器收回一个ICMP过错不可达报文。此时计算机A又会记录大型网络的IP。TTL会顺次的减少，直到收到了失常的回应，示意说计算机A发送的报文，曾经被B收到了。此时，计算机A曾经收到了所有的门路机器的信息，此时就能够输入数据报在网络中走过的门路了 因而，Traceroute利用奇妙的利用了ICMP过错不可达报文的作用，每次将TTL加1，直到达到指标机器，记录通过的每一个机器的IP，因而来获取门路。这就是Traceroute利用的原理 看一波实际操作，在windows中能够应用tracert+域名/IP的命令来查看输入。Mac中有自带的工具能够应用 首先是能够看到百度的地址为：182.61.200.7。而后packets下边第一跳就是我的内网路由器地址192.168.0.1。第二跳来到的是113.45.64.1，这个应该就是小区的内网IP。后边的每一跳所通过的IP，能够间接在百度上搜一下是哪里的IP 如果想看到更加具体的跨省门路，能够追踪拜访github.com，因为这个服务器在美国，所以会比较慢 在疾速变动的技术中寻找不变，才是一个技术人的外围竞争力。知行合一，实践联合实际

新人拜访“您好，我是 TCP 服务的实习生，刚培训完，请问您就是 TCP 老司机吗？” 正坐在办公室悠闲喝着咖啡的我，差点一口喷出来，“哦哦，行，你终于来啦，看来几天前的资源申请通过了啊，老司机？” “浏览器老大这么叫你的，说你厉害，靠谱的很。” “好吧，既然来了，赶紧准备准备！这你的工作台。” 我放下手中的咖啡，走到了一个靠窗的工作台，指了指。 “好嘞。” 说着，刚来的小伙子走了过来。 工作台“好多工具啊，这个通道是什么，这儿还有个钟？都怎么用呀？” 小伙子满脸好奇的问道。 “这样吧，从左到右，我一一给你说说。” “首先，最左边呢，是个通道，这里会蹦出应用层需要我们发送的数据。最常见的就是 HTTP 那小子的报文了。” “了解，我们的工作就是发送应用层的数据。原来不需要我们自己去拿啊！” “旁边呢就是扫描机，你需要根据实际情况把数据进行扫描，扫描机会把数据分块，按序号，放在旁边这个盒子里。” “嗯嗯，这个我清楚，数据块大小需要根据实时的网络情况确定。” “不错。这小伙子脑子还挺灵光。看来培训的不错” 我心中暗暗赞到。 “再往右，你看到这又是一个通道，这个通道就是我们和服务器进行沟通的通道了。通道旁是两个计数器，分别用来记录我们的序号和服务器序号，这个会自动加，你不用操作。就叫 1 号计数器和 2 号计数器吧，等下会用到。” “好的，1 号计数器其实就是报文中的序号？” “嗯嗯，不错，用的时候看一眼就行，在计数器旁边有几个按钮，我给你说说。这里最好记一下。” “嗯嗯” 说着小伙子拿出了笔记本开始记录。 任务降临我指了指标着 SYN 的按钮，说道：“这个是请求连接按钮，也就是通知服务器，我们想发数据给他。” 说着，最左侧的通道突然一闪，蹦出了一个 HTTP 服务打包好的包裹，刚来的小兄弟显的有点慌乱，咽了一口气。 “刚好，那我就那这给给你做一下演示吧。” 说着，我站到了工作台正中。 “嗯。” 小兄弟紧张的说不出话来。 “首先呢，按一下 SYN 按钮，请求发送数据。” 1 号计数器跳了一下，由原本的 0 跳到了 1。“按下这个按钮工作台会发送一个请求连接报文，相信报文的内容你应该清楚吧？” 我问道。 “SYN 为 1，序号为 0。” 看了一眼 1 号计数器，小伙子自信的答道。 “嗯，不错！” 不一会计数器旁的通道蹦出了一段报文，2 号计数器直接由 0 跳到了 11。 “让我们来看看，都有什么，你看这里。” 我指了指报文中的 ACK，小伙子也靠了过来。 ...

自定义报头协议在学习过计算机网络的课程,我们知道刚开始计算机都是单独脱机工作的,没有联网的情况下计算机的信息共享能力、运算能力都非常有限,后来诞生了计算机网络.有了就是那几网络,计算机 A 的信息和数据可以通过网络传递到计算机 B,同样计算机 A 可以获取到来自计算机 B 的数据. 但是不同计算机之间交换数据的时候就要通过网络来传输了.传输的过程中需要不同的计算机都遵循一定的规则来组装数据、传递信息,那么这样的规则就叫做协议.1. 协议计算机网络中有非常多协议,这些协议位于 OSI 的不同层中,比如 TCP/IP、UDP、SMTP、FTP 等. 协议之所以称为协议,是因为它具有约束效应,信息在端到端的传输过程中,同等层次之间通过使用同样的协议规则,这样发送方在该层次按照协议约定处理数据,接收方在该层次按照协议约定解析数据.成对存在. 2. 自定义协议在日常开发的时候处于某些原因可能需要自定义报文协议.这个协议是建立在 TCP 连接的基础上,比如,移动端在做 APM 的时候将功能拆分为2个模块,一个是 APM 监控模块、一个为了方便可拓展单独做了一个数据上报组件,具有动态下发上报策略的配置. 所以上报组件这里涉及到和服务端高效通信,所以客户端和服务端约定了一套自定义的报文协议,如下所示. PACKET 整体结构| HEAD | META | BATCH_PAYLOAD |PACKET::HEAD 结构| META_SIZE (2bytes unsigned int) | BATCH_COUNT (1 bytes unsigned int) | PAYLOAD_SIZE (4bytes unsigned int) | PAYLOAD_SIZE (4bytes unsigned int) | ... | PACKET::META 结构换行符分割的 JSON 字符串 crypto(deflate(JSONnJSON...)) PACKET::BATCH_PAYLOAD 结构JSON 体里每个字段的值都是 BASE64 编码的 ...

一、经典http面试题大纲1.什么是HTTP协议？★☆2.Web客户端是什么？☆3.Web服务端是什么？☆4.什么是资源？★5.MIME类型是什么？★☆6.什么是URI？★7.什么是URL？★8.什么是URN？★9.常见的HTTP方法有哪些？★☆10.常见的状态码200，206，302，304，404，501的含义？★★☆11.什么是报文？★★☆12.HTTP协议栈是怎么样的？★★★13.什么是DNS？★14.什么是端口号？★15.在浏览器地址栏输入一个HTTP的URL地址，按下回车键之后，浏览器怎么通过HTTP显示位于远端服务器中的某个简单HTML资源？★★★☆16.什么是代理？★☆17.什么是缓存？★☆18.什么是网关？★☆19.什么是隧道？★☆20.什么是Agent代理？★☆ 二、http面试题详解1.什么是HTTP协议？★☆HTTP:超文本传输协议。使用的是可靠的数据传输协议，在传输的过程中不会被损坏或产生混乱。HTTP可以从遍布全世界的Web服务器商将各种信息块迅速、便捷、可靠地搬移到人们桌面上的Web浏览器上去。 2.Web客户端是什么？☆Web客户端常见的又各大厂商的浏览器，比如微软的IE浏览器，google的chrome浏览器。 3.Web服务端是什么？☆Web服务器存储Web类容。Web服务器使用HTTP协议，被称为HTTP服务器。客户端向服务器发送HTTP请求，服务器会在HTTP响应中回送所请求的数据。 4.什么是资源？★Web资源寄宿在Web服务器上。所有能够提供Web内容的东西都是Web资源。比如静态文件，能够动态生成内容的软件程序。 5.MIME类型是什么？★☆MIME：多用途因特网邮件扩展。最初设计MIME是为了解决在不同的电子邮件系统之间搬移报文时存在的问题。HTTP采纳了它，用来描述并标记多媒体内容。MIME类型时一种文本标记，标识一种主要的对象类型和一个特定的子类型，中间由一条斜杠来分隔。如text/html,text/plain,image/ipeg。常见的MIME类型有数百个。 6.什么是URI？★URI：统一资源标识符，在世界范围内唯一标识并定位信息资源。URI有两种形式：URL和URN。 7.什么是URL？★URL：统一资源定位符。URL描述了一台特定服务器上某资源的特定位置。URL的第一部分被称为方案（scheme）。说明了访问资源所使用的协议类型。这里使用的时HTTP协议（http://）。第二部分表示服务器的因特网地址：www.cnblogs.com。其余部分指定了Web服务器上的某个资源：/jackson0714/p/algorithm_1.html。几乎所有的URLI都是URL。 8.什么是URN？★URN:统一资源名，URN是作为特定内容的唯一名称使用的，与目前的资源所在地无关。 9.常见的HTTP方法有哪些？★☆GET ：从服务器向客户端发送命名资源POST： 将客户端数据发送到一个服务器网关应用程序PUT： 将来自客户端的数据存储到一个命名的服务器资源中去DELETE： 从服务器中删除命名资源HEAD： 仅发送命名资源响应中的HTTP首部  10.常见的状态码200，206，302，304，404，503的含义？★★☆   11.什么是报文？★★☆HTTP报文是由一行一行的简单的字符串组成的。HTTP报文都是纯文本，不是二进制代码。 请求报文：从Web客户端发往Web服务器的HTTP报文称为请求报文。响应报文：从Web服务器发往客户端的报文称为响应报文。 HTTP报文包含以下三个部分：起始行：报文的第一行就是起始行，在请求报文中用来说明要做些什么，在响应报文中说明出现了什么情况。如：GET /jackson0714/p/algorithm_1.html HTTP/1.1首部字段：起始行后面由零个或多个首部字段。以键值对的形式表示首部字段。键和值之间用冒号分隔。首部以一个空行结束。如Content-Type：text/html:charset=utf-8主体：首部字段空行之后就是可选的报文主体了，其中包含了所有类型的数据。请求主体中包括了要发送Web服务器的数据，响应主体中装载了要返回给客户端的数据。 12.HTTP协议栈是怎么样的？★★★HTTP是应用层协议。它把联网的细节都交给了通用、可靠的因特网传输协议TCPIP协议。HTTP网络协议栈: TCP协议：　a.传输控制协议　b.无差错的数据传输　c.按序传输（数据总是会按照发送的顺序到达）　d.未分段的数据流（可以在任意时刻以任意尺寸将数据发送出去） 13.什么是DNS？★域名解析服务。将主机名转换为IP地址。如将http://www.cnblogs.com/ 主机名转换为IP地址：211.137.51.78。 14.什么是端口号？★http://www.cnblogs.com:8080就是端口号。HTTP的URL中没有端口号时，可以假设默认端口号时80。有了IP地址和端口号，客户端就可以很方便地通过TCP/IP进行通信了。 15.在浏览器地址栏输入一个HTTP的URL地址，按下回车键之后，浏览器怎么通过HTTP显示位于远端服务器中的某个简单HTML资源？★★★☆（1）浏览器从URL中解析出服务器的主机名；（2）浏览器将服务器的主机名转换成服务器的IP地址；（3）浏览器将端口号（如果有的话），从URL中解析出来；（4）浏览器建立一条与Web服务器的TCP连接；（5）浏览器向服务器发送一条HTTP请求报文；（6）服务器向浏览器回送一条HTTP响应报文；（7）关闭连接，浏览器显示文档。 16.什么是代理？★☆代理是位于客户端和服务器之间的HTTP中间实体。接收所有客户端的HTTP请求，并将这些请求转发给服务器（可能会对请求进行修改之后转发）。 17.什么是缓存？★☆缓存HTTP的仓库，使常用页面的副本可以保存在离客户端更近的地方。 18.什么是网关？★☆网关是一种特殊的服务器，作为其他服务器的中间实体使用。通常用于将HTTP流量转换成其他的协议。 19.什么是隧道？★☆隧道是建立起来之后，就会在两条连接之间对原始数据进行盲转发的HTTP应用程序。常见用途是通过HTTP连接承载加密的安全套接字层（SSL）流量，这样SSL流量就可以穿过只允许Web流量通过的防火墙了。 20.什么是Agent代理？★☆用户Agent代理是代表用户发起HTTP的客户端程序。比如Web浏览器。另外有些自动发送HTTP请求并获取内容的代理,比如“网络蜘蛛”或者“Web机器人”。 如果你觉得这篇文章对你有所帮助，那就顺便点个赞吧，点赞收藏不迷路~ 黑芝麻哇，白芝麻发，黑芝麻白芝麻哇发哈！ 前端哇发哈

【被黑➕扣78541466】简单介绍因为你的盈利超出平台底线，或者是平台觉得你已经没有继续压榨的价值了，那么他们就会盯上你号里的最后的那些分，找各种借口不给你出，这个时候正常的方法已经是不管用了，坦然的我随便的简述一些技巧，①藏分②欺骗③威胁至于怎么去使用，可以到我的企鹅78//54//14//66 日志上看笔记或是一对一的了解详情。 人的一生中无论在生活中还是在工作中都会遇到这样那样的困难，我觉得从以下几点着手去面对困难。 1、要保持良好的心态：要知道人的一生中遇到困难是必然的，当你遇到困难时，良好的心态是解决问题的根本，要相信没有跨不过去的坎。 2、仔细分析问题的实质：要清楚困难产生的原因，看到问题的实质而不仅仅是表面现象。 3、冷静面对积极应对：不要慌张，不要愁怅，根据分析的原因，找到应对的办法。 4、求助别人：将遇到的问题好好的和身边的人说说，总会有遇到过相同问题的人帮你找到解决的办法。 5、吸取教训：把遇到的困难当成是人生的经历，并从中举一反三，总结原因，避免再一次遇到相同的困难。 以上只是个人意见，仅供参考！最好的办法就戒掉，不再踏上这条路，也就不会有机可乘。

本文出处https://shenyifengtk.github.io/如有转载，请说明出处socks5 介绍socks5s是一种网络传输协议，主要用于客户端与外网服务器之间通讯的中间传递。当防火墙后的客户端要访问外部的服务器时，就跟SOCKS代理服务器连接。这个代理服务器控制客户端访问外网的资格，允许的话，就将客户端的请求发往外部的服务器。 根据OSI模型，SOCKS是会话层的协议，位于表示层与传输层之间，也就是说socks是在TCP 之上的协议。 和HTTP代理相比HTTP代理只能代理http请求，像TCP、HTTPS这些协议显得很无力，有一定的局限性。SOCKS工作在比HTTP代理更低的层次：SOCKS使用握手协议来通知代理软件其客户端试图进行的连接SOCKS，然后尽可能透明地进行操作，而常规代理可能会解释和>重写报头（例如，使用另一种底层协议，例如FTP；然而，HTTP代理只是将HTTP请求转发到所需的HTTP服务器）。虽然HTTP代理有不同的使用模式，CONNECT方法允许转发TCP连接；然而，SOCKS代理还可以转发UDP流量和反向代理，而HTTP代理不能。HTTP代理通常更了解HTTP协议，执行更高层次的过滤（虽然通常只用于GET和POST方法，而不用于CONNECT方法）。 SOCKS协议内容官方协议RFC选择认证方法大体说下socks连接过程，首先客户端发送一个数据包到socks代理 VarNMETHODSMETHODS110-255表格里面的单位表示位数 Var 表示是SOCK版本，应该是５;NMETHODS 表示 METHODS部分的长度METHODS 表示支持客户端支持的认证方式列表，每个方法占1字节。当前的定义是 0x00 不需要认证0x01 GSSAPI0x02 用户名、密码认证0x03 - 0x7F由IANA分配（保留）0x80 - 0xFE为私人方法保留0xFF 无可接受的方法服务器会响应给客户端 VERMETHOD11Var 表示是SOCK版本，应该是５;METHOD是服务端选中方法，这个的值为上面METHODS 列表中一个。如果客户端支持0x00，0x01，0x02，这三个方法。服务器只会选中一个认证方法返回给客户端，如果返回0xFF表示没有一个认证方法被选中，客户端需要关闭连接。我们先用一个简单Nodejs在实现sock连接握手.查看客户端发送数据报 const net = require('net');let server = net.createServer(sock =>{sock.once('data', (data)=>{console.log(data);});});server.listen(8888,'localhost');使用curl工具连接nodejs curl -x socks5://localhost:8888 https://www.baidu.comconsole输出 <Buffer 05 02 00 01>使用账号密码认证当服务器选择0x02 账号密码方式认证后，客户端开始发送账号 、密码，数据包格式如下: (以字节为单位) VERULENUNAMEPLENPASSWD111 to 25511 to 255VER是SOCKS版本ULEN 用户名长度UNAME 账号stringPLEN 密码长度PASSWD 密码string可以看出账号密码都是明文传输，非常地不安全。服务器端校验完成后，会响应以下数据(): VERSTATUS11STATUS 0x00 表示成功，0x01 表示失败封装请求认证结束后客户端就可以发送请求信息。客户端开始封装请求信息SOCKS5请求格式（以字节为单位）： VERCMDRSVATYPDST.ADDRDST.PORT110x001动态2VER是SOCKS版本，这里应该是0x05；CMD是SOCK的命令码 0x01表示CONNECT请求 CONNECT请求可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道（tunnel）。例如，CONNECT 可以用来访问采用了 SSL is a standard protocol that ensures communication sent between two computer applications is private and secure (cannot be read nor changed by outside observers). It is the foundation for the TLS protocol.") (HTTPS is an encrypted version of the HTTP protocol. It usually uses SSL or TLS to encrypt all communication between a client and a server. This secure connection allows clients to safely exchange sensitive data with a server, for example for banking activities or online shopping.")) 协议的站点。客户端要求代理服务器将 TCP 连接作为通往目的主机隧道。之后该服务器会代替客户端与目的主机建立连接。连接建立好之后，代理服务器会面向客户端发送或接收 TCP 消息流。0x02表示BIND请求 ...

作为互联网通信协议的一员老将，HTTP 协议走到今天已经经历了三次版本的变动，现在最新的版本是 HTTP2.0，相信大家早已耳熟能详。今天就给大家好好介绍一下 HTTP 的前世今生。1、http的历史简介先简单的介绍一下，后面再具体详解1.1、HTTP/0.9HTTP 的最早版本诞生在 1991 年，这个最早版本和现在比起来极其简单，没有 HTTP 头，没有状态码，甚至版本号也没有，后来它的版本号才被定为 0.9 来和其他版本的 HTTP 区分。HTTP/0.9 只支持一种方法—— Get，请求只有一行。GET /hello.html响应也是非常简单的，只包含 html 文档本身。<HTML>Hello world</HTML>当 TCP 建立连接之后，服务器向客户端返回 HTML 格式的字符串。发送完毕后，就关闭 TCP 连接。由于没有状态码和错误代码，如果服务器处理的时候发生错误，只会传回一个特殊的包含问题描述信息的 HTML 文件。这就是最早的 HTTP/0.9 版本。1.2、HTTP/1.01996 年，HTTP/1.0 版本发布，大大丰富了 HTTP 的传输内容，除了文字，还可以发送图片、视频等，这为互联网的发展奠定了基础。相比 HTTP/0.9，HTTP/1.0 主要有如下特性：请求与响应支持 HTTP 头，增加了状态码，响应对象的一开始是一个响应状态行协议版本信息需要随着请求一起发送，支持 HEAD，POST 方法支持传输 HTML 文件以外其他类型的内容 一个典型的 HTTP/1.0 的请求像这样：GET /hello.html HTTP/1.0User-Agent:NCSA_Mosaic/2.0(Windows3.1)200 OKDate: Tue, 15 Nov 1996 08:12:31 GMTServer: CERN/3.0 libwww/2.17Content-Type: text/html<HTML>一个包含图片的页面<IMGSRC="/smile.gif"></HTML>1.3、HTTP/1.1在 HTTP/1.0 发布几个月后，HTTP/1.1 就发布了。HTTP/1.1 更多的是作为对 HTTP/1.0 的完善，在 HTTP1.1 中，主要具有如下改进：可以复用连接增加 pipelinechunked 编码传输引入更多缓存控制机制引入内容协商机制请求消息和响应消息都支持 Host 头域新增了 OPTIONS,PUT, DELETE, TRACE, CONNECT 方法1.4、 HTTPSHTTPS 是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。HTTPS 协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。 HTTPS 和 HTTP 的区别主要如下：HTTPS 协议使用 ca 申请证书，由于免费证书较少，需要一定费用。HTTP 是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。HTTP 和 HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。1.5、SPDY在 2010 年到 2015 年，谷歌通过实践一个实验性的 SPDY 协议，证明了一个在客户端和服务器端交换数据的另类方式。其收集了浏览器和服务器端的开发者的焦点问题，明确了响应数量的增加和解决复杂的数据传输。在启动 SPDY 这个项目时预设的目标是：页面加载时间 (PLT) 减少 50%。无需网站作者修改任何内容。将部署复杂性降至最低，无需变更网络基础设施。与开源社区合作开发这个新协议。收集真实性能数据，验证这个实验性协议是否有效。为了达到降低目标，减少页面加载时间的目标，SPDY 引入了一个新的二进制分帧数据层，以实现多向请求和响应、优先次序、最小化及消除不必要的网络延迟，目的是更有效地利用底层 TCP 连接。1.6、 HTTP/2.0时间来到 2015 年，HTTP/2.0 问世。先来介绍一下 HTTP/2.0 的特点吧：使用二进制分帧层多路复用数据流优先级服务端推送头部压缩2、http原理详解HTTP协议是构建在TCP/IP协议之上的，是TCP/IP协议的一个子集，所以要理解HTTP协议，有必要先了解下TCP/IP协议相关的知识。2.1 TCP/IP协议TCP/IP协议族是由一个四层协议组成的系统，这四层分别为：应用层、传输层、网络层和数据链路层分层的好处是把各个相对独立的功能解耦，层与层之间通过规定好的接口来通信。如果以后需要修改或者重写某一个层的实现，只要接口保持不变也不会影响到其他层的功能。接下来，我们将会介绍各个层的主要作用。1) 应用层应用层一般是我们编写的应用程序，其决定了向用户提供的应用服务。应用层可以通过系统调用与传输层进行通信。处于应用层的协议非常多，比如：FTP（File Transfer Protocol，文件传输协议）、DNS（Domain Name System，域名系统）和我们本章讨论的HTTP（HyperText Transfer Protocol，超文本传输协议）等。2) 传输层传输层通过系统调用向应用层提供处于网络连接中的两台计算机之间的数据传输功能。在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和UDP（User Data Protocol，用户数据报协议）。3) 网络层网络层用来处理在网络上流动的数据包，数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（传输路线）到达对方计算机，并把数据包传输给对方。IP协议4) 链路层链路层用来处理连接网络的硬件部分，包括控制操作系统、硬件设备驱动、NIC（Network Interface Card，网络适配器）以及光纤等物理可见部分。硬件上的范畴均在链路层的作用范围之内。数据包封装上层协议数据是如何转变为下层协议数据的呢？这是通过封装（encapsulate）来实现的。应用程序数据在发送到物理网络之前，会沿着协议栈从上往下传递。每层协议都将在上层协议数据的基础上加上自己的头部信息（链路层还会加上尾部信息），以为实现该层功能提供必要的信息.发送端发送数据时，数据会从上层传输到下层，且每经过一层都会被打上该层的头部信息。而接收端接收数据时，数据会从下层传输到上层，传输前会把下层的头部信息删除.由于下层协议的头部信息对上层协议是没有实际的用途，所以在下层协议传输数据给上层协议的时候会把该层的头部信息去掉，这个封装过程对于上层协议来说是完全透明的。这样做的好处是，应用层只需要关心应用服务的实现，而不用管底层的实现。TCP三次握手从上面的介绍可知，传输层协议主要有两个：TCP协议和UDP协议。TCP协议相对于UDP协议的特点是：TCP协议提供面向连接、字节流和可靠的传输。第一次握手：客户端发送带有SYN标志的连接请求报文段，然后进入SYN_SEND状态，等待服务端的确认。第二次握手：服务端接收到客户端的SYN报文段后，需要发送ACK信息对这个SYN报文段进行确认。同时，还要发送自己的SYN请求信息。服务端会将上述的信息放到一个报文段（SYN+ACK报文段）中，一并发送给客户端，此时服务端将会进入SYN_RECV状态。第三次握手：客户端接收到服务端的SYN+ACK报文段后，会想服务端发送ACK确认报文段，这个报文段发送完毕后，客户端和服务端都进入ESTABLISHED状态，完成TCP三次握手。当三次握手完成后，TCP协议会为连接双方维持连接状态。为了保证数据传输成功，接收端在接收到数据包后必须发送ACK报文作为确认。如果在指定的时间内（这个时间称为重新发送超时时间），发送端没有接收到接收端的ACK报文，那么就会重发超时的数据。2.2、 DNS 域名解析当你在浏览器的地址栏输入 https://juejin.im 后会发生什么，大家在心中肯定是有一个大概的，这里我将 DNS 域名解析 这个步骤详细的讲一遍。在讲概念之前我先放上一张经典的图文供大家思考一分钟。查找域名对应的 IP 地址的具体过程浏览器搜索自己的 DNS 缓存（浏览器维护一张域名与 IP 地址的对应表）；如果没有命中，进入下一步；搜索操作系统中的 DNS 缓存；如果没有命中，进入下一步；搜索操作系统的 hosts 文件（ Windows 环境下，维护一张域名与 IP 地址的对应表）；如果没有命中，进入下一步；列表项目操作系统将域名发送至 LDNS （本地区域名服务器），LDNS 查询自己的 DNS 缓存（一般命中率在 80% 左右），查找成功则返回结果，失败则发起一个迭代 DNS 解析请求：LDNS向 Root Name Server（根域名服务器，如com、net、im 等的顶级域名服务器的地址）发起请求，此处，Root Name Server 返回 im 域的顶级域名服务器的地址；LDNS 向 im 域的顶级域名服务器发起请求，返回 juejin.im 域名服务器地址；LDNS 向 juejin.im 域名服务器发起请求，得到 juejin.im 的 IP 地址；LDNS 将得到的 IP 地址返回给操作系统，同时自己也将 IP 地址缓存起来；操作系统将 IP 地址返回给浏览器，同时自己也将 IP 地址缓存起来。http工作的简单过程地址解析： 这一步比较重要的是上面的DNS解析封装HTTP请求数据包： 把以上部分结合本机自己的信息，封装成一个HTTP请求数据包封装成TCP包，建立TCP连接（TCP的三次握手）客户机发送请求命令服务器响应服务器关闭TCP连接2.3、http请求方法一些常见的http请求方法。GET： 用于获取数据POST： 用于将实体提交到指定的资源，通常导致状态或服务器上的副作用的更改HEAD： 与GET请求的响应相同的响应，但没有响应体PUT： 用于创建或更新指定资源DELETE： 删除指定的资源关于get与post的一些区别。可以看我的另一篇文章面试经典之http中get与post的区别2.4、 http缓存http很重要的一点还有他的缓存机制。关于这部分的内容可以看一下我之前的文章浏览器缓存看这一篇就够了。这里就不在赘述了。2.5、状态码这里主要讲一些常用的状态码1、 301 永久转移当你想换域名的时候，就可以使用301，如之前的域名叫www.renfed.com，后来换了一个新域名fed.renren.com，希望用户访问老域名的时候能够自动跳转到新的域名，那么就可以使用nginx返回301：server { listen 80; server_name www.renfed.com; root /home/fed/wordpress; return 301 https://fed.renren.com$request_uri;}浏览器收到301之后，就会自动跳转了。搜索引擎在爬的时候如果发现是301，在若干天之后它会把之前收录的网页的域名给换了。还有一个场景，如果希望访问http的时候自动跳转到https也是可以用301，因为如果直接在浏览器地址栏输入域名然后按回车，前面没有带https，那么是默认的http协议，这个时候我们希望用户能够访问安全的https的，不要访问http的，所以要做一个重定向，也可以使用301，如：server { listen 80; server_name fed.renren.com; if ($scheme != “https”) { return 301 https://$host$request_uri; } }2、302 Found 资源暂时转移很多短链接跳转长链接就是使用的302，如下图所示：3、304 Not Modified 没有修改这个主要在上面的缓存哪里出现的比较多。如果服务器没有修改。就会使用浏览器的缓存。4、400 Bad Request 请求无效当必要参数缺失、参数格式不对时，后端通常会返回400，如下图所示：5、403 Forbidden 拒绝服务服务能够理解你的请求，包括传参正确，但是拒绝提供服务。例如，服务允许直接访问静态文件，但是不允许访问某个目录：否则，别人对你服务器上的文件就一览无遗了。403和401的区别在于，401是没有认证，没有登陆验证之类的错误。6、500 内部服务器错误如业务代码出现了异常没有捕获，被tomcat捕获了，就会返回500错误：如：数据库字段长度限制为30个字符，如果没有判断直接插入一条31个字符的记录，就会导致数据库抛异常，如果异常没有捕获处理，就直接返回500。当服务彻底挂了，连返回都没有的时候，那么就是502了。7、502 Bad Gateway 网关错误这种情况是因为nginx收到请求，但是请求没有打过去，可能是因为业务服务挂了，或者是打过去的端口号写错了8、504 Gateway Timeout 网关超时通常是因为服务处理请求太久，导致超时，如PHP服务默认的请求响应最长处理时间为30s，如果超过30s，将会挂掉，返回504，如下图所示：2.6、HTTP的基本优化影响一个HTTP网络请求的因素主要有两个：带宽和延迟。带宽如果说我们还停留在拨号上网的阶段，带宽可能会成为一个比较严重影响请求的问题，但是现在网络基础建设已经使得带宽得到极大的提升，我们不再会担心由带宽而影响网速，那么就只剩下延迟了。延迟1、浏览器阻塞（HOL blocking）：浏览器会因为一些原因阻塞请求。浏览器对于同一个域名，同时只能有 4 个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。2、DNS 查询（DNS Lookup）：浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。3、建立连接（Initial connection）：HTTP 是基于 TCP 协议的，浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大http的发展也就是在不断地优化这些方向上的问题。3、http1.1HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。虽然 HTTP/1.1 已经优化了很多点，作为一个目前使用最广泛的协议版本，已经能够满足很多网络需求，但是随着网页变得越来越复杂，甚至演变成为独立的应用，HTTP/1.1 逐渐暴露出了一些问题：在传输数据时，每次都要重新建立连接，对移动端特别不友好传输内容是明文，不够安全header 内容过大，每次请求 header 变化不大，造成浪费keep-alive 给服务端带来性能压力 为了解决这些问题，HTTPS 和 SPDY 应运而生。4、HTTPSHTTPS 是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。5、SPDY：HTTP1.x的优化2012年google如一声惊雷提出了SPDY的方案，优化了HTTP1.X的请求延迟，解决了HTTP1.X的安全性，具体如下：降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。服务端推送（server push），采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。SPDY构成图：SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议(将HTTP1.x的内容封装成一种新的frame格式)，同时可以使用已有的SSL功能。6、HTTP2.0HTTP2.0可以说是SPDY的升级版（其实原本也是基于SPDY设计的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，如下：HTTP2.0和SPDY的区别：HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPSHTTP2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATEHTTP/2 新特性6.1、二进制传输HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效。 HTTP / 1 的请求和响应报文，都是由起始行，首部和实体正文（可选）组成，各部分之间以文本换行符分隔。HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。接下来我们介绍几个重要的概念：流：流是连接中的一个虚拟信道，可以承载双向的消息；每个流都有一个唯一的整数标识符（1、2…N）；消息：是指逻辑上的 HTTP 消息，比如请求、响应等，由一或多个帧组成。帧：HTTP 2.0 通信的最小单位，每个帧包含帧首部，至少也会标识出当前帧所属的流，承载着特定类型的数据，如 HTTP 首部、负荷，等等HTTP/2 中，同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。6.2、多路复用在 HTTP/2 中引入了多路复用的技术。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题，同时也接更容易实现全速传输，毕竟新开一个 TCP 连接都需要慢慢提升传输速度。在 HTTP/2 中，有了二进制分帧之后，HTTP /2 不再依赖 TCP 链接去实现多流并行了，在 HTTP/2中：同域名下所有通信都在单个连接上完成。单个连接可以承载任意数量的双向数据流。数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装。这一特性，使性能有了极大提升：同个域名只需要占用一个 TCP 连接，使用一个连接并行发送多个请求和响应,消除了因多个 TCP 连接而带来的延时和内存消耗。并行交错地发送多个请求，请求之间互不影响。并行交错地发送多个响应，响应之间互不干扰。在HTTP/2中，每个请求都可以带一个31bit的优先值，0表示最高优先级， 数值越大优先级越低。有了这个优先值，客户端和服务器就可以在处理不同的流时采取不同的策略，以最优的方式发送流、消息和帧。如上图所示，多路复用的技术可以只通过一个 TCP 连接就可以传输所有的请求数据。6.3、Header 压缩在 HTTP/1 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。为了减少这块的资源消耗并提升性能， HTTP/2对这些首部采取了压缩策略：HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送；首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新;每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值例如下图中的两个请求， 请求一发送了所有的头部字段，第二个请求则只需要发送差异数据，这样可以减少冗余数据，降低开销6.4、服务端推送（Server Push）Server Push即服务端能通过push的方式将客户端需要的内容预先推送过去，也叫“cache push”。可以想象以下情况，某些资源客户端是一定会请求的，这时就可以采取服务端 push 的技术，提前给客户端推送必要的资源，这样就可以相对减少一点延迟时间。当然在浏览器兼容的情况下你也可以使用 prefetch。例如服务端可以主动把JS和CSS文件推送给客户端，而不需要客户端解析HTML时再发送这些请求。服务端可以主动推送，客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略，换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方确认才行。后续更多文章将在我的github第一时间发布，欢迎关注。参考HTTP协议详解前端词典】进阶必备的网络基础我知道的HTTP请求一文读懂HTTP/2 及 HTTP/3特性 ...

GET和POST是HTTP请求的两种基本方法，要说它们的区别，接触过WEB开发的人都能说出一二。最直观的区别就是GET把参数包含在URL中，POST通过request body传递参数。你可能自己写过无数个GET和POST请求，或者已经看过很多权威网站总结出的他们的区别，你非常清楚知道什么时候该用什么。1、常规答案当你在面试中被问到这个问题，你的内心充满了自信和喜悦。你轻轻松松的给出了一个“标准答案”：-GETPOST后退按钮/刷新无害数据会被重新提交（浏览器应该告知用户数据会被重新提交）。书签可收藏为书签不可收藏为书签缓存能被缓存不能缓存编码类型application/x-www-form-urlencoded 只能进行url编码application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。历史参数保留在浏览器历史中。参数不会保存在浏览器历史中。对数据长度的限制是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。无限制。对数据类型的限制只允许 ASCII 字符。没有限制。也允许二进制数据。安全性与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET ！POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。可见性数据在 URL 中对所有人都是可见的。数据不会显示在 URL 中。“很遗憾，这不是我们要的回答！”请告诉我真相。。。2、本质区别如果我告诉你GET和POST本质上没有区别你信吗？ 让我们扒下GET和POST的外衣，坦诚相见吧！GET和POST是什么？HTTP协议中的两种发送请求的方法。HTTP是什么？HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。2.1 那么，“标准答案”里的那些区别是怎么回事？在我大万维网世界中，TCP就像汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET, POST, PUT, DELETE等等，HTTP规定，当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里。当然，你也可以在GET的时候往车厢内偷偷藏点货物，但是这是很不光彩；也可以在POST的时候在车顶上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。但是，我们只看到HTTP对GET和POST参数的传送渠道（url还是requrest body）提出了要求。2.2、“标准答案”里关于参数大小的限制又是从哪来的呢？在我大万维网世界中，还有另一个重要的角色：运输公司。不同的浏览器（发起http请求）和服务器（接受http请求）就是不同的运输公司。 虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到哦。好了，现在你知道，GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。2.3、最终boss你以为本文就这么结束了？我们的大BOSS还等着出场呢。。。这位BOSS有多神秘？当你试图在网上找“GET和POST的区别”的时候，那些你会看到的搜索结果里，从没有提到他。他究竟是什么呢。。。GET和POST还有一个重大区别，简单的说：GET产生一个TCP数据包；POST产生两个TCP数据包。也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？GET与POST都有自己的语义，不能随便混用。据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。好了，看到这里之后再也不怕面试官问get与post请求的区别了。

原文链接最近又看了一遍 [HTTP权威指南]，每次想写一份总结的时候都会拖延症爆发，今天决定总结下我们每天都在接触的HTTP。OSI (Open System Interconnect)先列一张能够体现不同协议在OSI七层模型中的表格层级层级名称应用7应用层例如HTTP、SMTP、SNMP、FTP、Telnet、SIP、SSH、NFS、RTSP、XMPP、Whois、ENRP、TLS6表示层例如XDR、ASN.1、SMB、AFP、NCP5会话层例如ASAP、ISO 8327 / CCITT X.225、RPC、NetBIOS、ASP、IGMP、Winsock、BSD sockets4传输层例如TCP、UDP、RTP、SCTP、SPX、ATP、IL3网络层例如IP、ICMP、IPX、BGP、OSPF、RIP、IGRP、EIGRP、ARP、RARP、X.252数据链路层例如以太网、令牌环、HDLC、帧中继、ISDN、ATM、IEEE 802.11、FDDI、PPP1物理层例如线路、无线电、光纤先从 TCP/IP 说起IPS（Internet Protocol Suite）又叫做互联网协议套件、是一套网络传输协议家族，也就是我们熟悉的TCP/IP协议族，（又因为TCP、IP为不同层级的协议，当多个层级的协议共同工作时类似计算机科学中的堆栈、所以又叫做TCP/IP协议栈）TCP/IP 中包含一系列用于处理数据通信的协议TCP (传输控制协议) - 应用程序之间通信UDP (用户数据报协议) - 应用程序之间的简单通信IP (网际协议) - 计算机之间的通信ICMP (因特网消息控制协议) - 针对错误和状态DHCP (动态主机配置协议) - 针对动态寻址这里要说一下TCP、HTTP、socket的关系实际上socket只是一个Api，方便我们去调用底层封装好的TCP/IP协议，但是socket与TCP/IP并没有必然的关系，socket接口在设计的时候就希望也能够适应其他协议，而HTTP是基于TCP之上的应用层协议，有一个很有趣的比喻就是如果TCP是高速路，那么HTTP就是高速路上的货车。好，下面重头戏来了，TCP三次握手(建立连接)四次挥手(断开连接)客户端 - Client、 服务端 - Server 两个整型变量 J、K三次握手(建立连接)Server socket绑定端口，等待消息(first) Client 打开socket(connect) 、发送 SYN J(second) Server 收到消息，向客户端发送 SYN K、 ack J+1(third) Client 收到应答、发送 ack K+1Server 开始读取Client发送的信息至此、连接建立完成、这里有一个问题，为什么建立连接不是2次握手、为什么不是4次握手？恰好是三次的原因是三次刚刚好，4次浪费网络资源没必要，而如果改为2次，那么client在向server发送第一次握手的时候因为某些原因舍弃了这次连接(或是因其他原因被迫强制关闭)而并没有通知Server，那么如果只需要2次握手无疑会造成server会一直处于盲等状态。四次挥手(连接拆除)三个整型变量 x、y、z与建立连接不同的是、断开连接可以由任意一方发起主动方发送fin=1、ack=z、seq=x被动方发送ack=x+1、seq=z被动方发送fin=1、ack=x、seq=y主动方发送ack=y、seq=x那么，为何挥手要挥4次呢，原因在于拆除连接时收到fin报文，仅仅代表对方不再发送数据，而接收到fin报文的一方可能还有数据没发送完，所以被动方的fin和ack要分开发送。HTTP 连接那么什么是HTTP连接呢，所谓HTTP，就是基于TCP/IP协议的上层应用层协议，所以我们可以理解HTTP连接就是以TCP/IP为传输层协议，以HTTP协议作为应用层协议的连接就比如我们在浏览器输入 https://k.felixplus.top/ 、会先通过 TCP握手建立连接，这个时候传输的数据会通过HTTP协议进行解析，最后到达我们的浏览器进行绘制展示HTTPSHTTPS = HTTP + (TLS/SSL)其中，TLS/SSL 为 HTTP 提供了安全加密传输的功效相比之下，HTTPS比HTTP多提供了以下几点：数据完整性：内容传输经过完整性校验数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥身份认证：第三方无法伪造服务端(客户端)身份那么，HTTPS的一次传输过程是怎样的呢，先说结论:Server 被动监听Client 发送连接请求Server 返回公钥Client 生成随机值（对称加密的私钥）通过Server返回的公钥加密Client 将密文发送回Server 并等待确认双方开始使用客户端生成的对称加密密钥进行通讯在继续之前我们需要先来回顾一下什么是对称加密，什么是非对称加密:对称方式加密方法风险加解密速度非对称数据的加解密由一个密钥解决风险较高加解密速度快对称数据使用公钥加密、私钥解密风险较小加解密速度慢从这里不难看出，HTTPS同时使用到对称加密和非对称加密的原因是如果数据传输量很大，一直使用非对称加密会消耗更多资源，产生不必要的浪费，而在传输数据之前先通过非对称加密发送客户端生成的私钥在安全性能上足以胜任，所以这里并没有完全使用非对称加密。下面是使用 curl 命令debug HTTPS 请求的输出curl -v https://aground.felixplus.top* Rebuilt URL to: https://aground.felixplus.top/* Trying 47.75.98.166…* TCP_NODELAY set* Connected to aground.felixplus.top (47.75.98.166) port 443 (#0)* ALPN, offering h2* ALPN, offering http/1.1* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH* successfully set certificate verify locations:* CAfile: /etc/ssl/cert.pem CApath: none* TLSv1.2 (OUT), TLS handshake, Client hello (1):* TLSv1.2 (IN), TLS handshake, Server hello (2):* TLSv1.2 (IN), TLS handshake, Certificate (11):* TLSv1.2 (IN), TLS handshake, Server key exchange (12):* TLSv1.2 (IN), TLS handshake, Server finished (14):* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):* TLSv1.2 (OUT), TLS change cipher, Client hello (1):* TLSv1.2 (OUT), TLS handshake, Finished (20):* TLSv1.2 (IN), TLS change cipher, Client hello (1):* TLSv1.2 (IN), TLS handshake, Finished (20):* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305* ALPN, server accepted to use h2* Server certificate:* subject: CN=aground.felixplus.top* start date: Feb 15 10:01:34 2019 GMT* expire date: May 16 10:01:34 2019 GMT* subjectAltName: host “aground.felixplus.top” matched cert’s “aground.felixplus.top”* issuer: C=US; O=Let’s Encrypt; CN=Let’s Encrypt Authority X3* SSL certificate verify ok.* Using HTTP2, server supports multi-use* Connection state changed (HTTP/2 confirmed)* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0* Using Stream ID: 1 (easy handle 0x7feef980b800)> GET / HTTP/2> Host: aground.felixplus.top> User-Agent: curl/7.54.0> Accept: />* Connection state changed (MAX_CONCURRENT_STREAMS updated)!< HTTP/2 200< server: nginx/1.14.0 (Ubuntu)< date: Mon, 25 Mar 2019 07:13:40 GMT< content-type: text/html< content-length: 2121< last-modified: Tue, 19 Mar 2019 09:57:48 GMT< vary: Accept-Encoding< etag: “5c90bd1c-849”< accept-ranges: bytes<* Connection #0 to host aground.felixplus.top left intact<!doctype html><html lang=“en”><head><meta charset=“utf-8”/><link rel=“shortcut icon” href="/panda.png"/><meta name=“viewport” content=“width=device-width,initial-scale=1,shrink-to-fit=no”/><meta name=“theme-color” content="#000000"/><link rel=“manifest” href="/manifest.json"/><title>AGround</title><link href="/static/css/2.4126af51.chunk.css" rel=“stylesheet”><link href="/static/css/main.85ae910b.chunk.css" rel=“stylesheet”></head><body><noscript>You need to enable JavaScript to run this app.</noscript><div id=“root”></div><script>!function(l){function e(e){for(var r,t,n=e[0],o=e[1],u=e[2],f=0,i=[];f<n.length;f++)t=n[f],p[t]&&i.push(p[t][0]),p[t]=0;for(r in o)Object.prototype.hasOwnProperty.call(o,r)&&(l[r]=o[r]);for(s&&s(e);i.length;)i.shift()();return c.push.apply(c,u||[]),a()}function a(){for(var e,r=0;r<c.length;r++){for(var t=c[r],n=!0,o=1;o<t.length;o++){var u=t[o];0!==p[u]&&(n=!1)}n&&(c.splice(r–,1),e=f(f.s=t[0]))}return e}var t={},p={1:0},c=[];function f(e){if(t[e])return t[e].exports;var r=t[e]={i:e,l:!1,exports:{}};return l[e].call(r.exports,r,r.exports,f),r.l=!0,r.exports}f.m=l,f.c=t,f.d=function(e,r,t){f.o(e,r)||Object.defineProperty(e,r,{enumerable:!0,get:t})},f.r=function(e){“undefined”!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:“Module”}),Object.defineProperty(e,"__esModule",{value:!0})},f.t=function(r,e){if(1&e&&(r=f(r)),8&e)return r;if(4&e&&“object”==typeof r&&r&&r.__esModule)return r;var t=Object.create(null);if(f.r(t),Object.defineProperty(t,“default”,{enumerable:!0,value:r}),2&e&&“string”!=typeof r)for(var n in r)f.d(t,n,function(e){return r[e]}.bind(null,n));return t},f.n=function(e){var r=e&&e.__esModule?function(){return e.default}:function(){return e};return f.d(r,“a”,r),r},f.o=function(e,r){return Object.prototype.hasOwnProperty.call(e,r)},f.p="/";var r=window.webpackJsonp=window.webpackJsonp||[],n=r.push.bind(r);r.push=e,r=r.slice();for(var o=0;o<r.length;o++)e(r[o]);var s=n;a()}([])</script><script src="/static/js/2.5167ae78.chunk.js"></script><script src="/static/js/main.05967284.chunk.js"></script></body></html>% ...

本章主要介绍网络协议，这个协议就叫做OSI协议（一系列协议），按照功能不同，分工不同，人为的分层七层。实际上这个七层是不存在的。没有这七层的概念，只是人为的划分而已。我们谈到在任何联网的协议时，就会谈到OSI（网络七层协议模型），必须遵循这个协议模型，我们的手机和电脑才可以联网通信，接下来我们就一起来看一下OSI（网络七层协议模型）七层协议OSI层功能TCP/IP协议应用层文本传输，电子邮件，文件服务，虚拟终端FTP,HTTP,SNMP,DNS等表示层数据格式化，代码转换，数据加密没有协议会话层解除或建立与其他节点的联系没有协议传输层提供端对端的接口TCP,UDP网络层为数据包选择路由IP,ICMP,RIP,OSPF,BGP,IGMP数据链路层传输有地址的帧，错误检测功能SLIP,CSLIP,PPP,ARP,RARP,MTU物理层以二进制数据形式在物理媒体上传输数据ISO2110,IEEE802,IEEE802.2以上是七层协议，业界还产生出了一些其他协议模型。例如TCP/IP四层协议以及五层协议。TCP/IP四层协议模型：主要包括：应用层传输层网络层物理链路层五层协议模型主要包括：应用层传输层网络层数据链路层物理层来自网图通过看上面硬性的概念，可能我们很难理解网络七层协议到底都是怎么一回事。接下来我会用一个小故事来帮助大家一起来理解记忆这网络七层协议。小故事我们的故事以五层协议为基础，小明表白小红为主线。小明暗恋小红很久了，可是却羞于当面表达爱意。于是他决定写一份email发给小红，来表白。万里长城第一步：小明从商店买了一堆物理线、网线接口、光纤等。一头连自己家，另一头连小红家。小明想到的第一个问题是：怎么才能让这个两个物理硬件之间进行通信呢？于是小明发明了比特流，通过 1与 0之间转化为电流的强弱进行信号的传输也就人们常说的数模转换与模数转换。这时候已经完成了第一步，两个物理硬件之间的通信。这也就是我们通常所说的物理层万里长城第二步：小明想啊：我这两个物理硬件之间已经完成了通信，但是我怎么确保传输的数据是可靠的、安全的呢？因为小明想要求这封信是可靠的，安全的。他不想别人知道他喜欢小红。因为在我们实际生活当中物理线路往往是不可靠，不安全的。可能会被别人偷听到，网线被别人挖了等等。于是小明发明了数据链路层。通过数据链路层来确保数据的正确传输。当中就有一个叫数据包的家伙，通过一个个数据包来传输数据。数据包通过奇偶校验的形式或者其他的形式来校验数据是不是正确的。这个时候我们就完成了一个节点到另外一个节点数据包的传递。万里长城第三步：小明心想，这时候我已经可以把信发送到小红家了，可是万一小红不在家呢？在学校或者在其他某个地方旅游呢？那岂不是看不到我的信了？这时候小明发明了网络层，即路由器。这时候小明会先把他的数据包发送给路由器，然后路由器发送给路由器，一路传过去，最后发送到了小红所在的电脑上，这就是网络层。同时，小明为了标识网络层的各个节点，他定义了Ip协议。因此每个节点都会有个IP。万里长城第四步：小明心想，这时候在我们数据链路层，能保证数据是否是正确的，但是不能保证我们的数据是不是可靠的。这个时候，我们需要一个能够保证我们数据传输出错后，能够自动重传机制。自动校验数据是否是发对了。这时候小明发明了传输层。在传输层里面小明又制定了TCP/UDP协议。TCP协议是基于连接的，会在小明和小红电脑之间建立连接，在这个连接上去传输数据。万里长城第五步：这时候小明该做的也做了。可是我们的数据是为哪个应用服务的呢？是一个HTTP?还是一个FTP?还是一个Email的协议呢？这个就是小明发明的最后一个协议——应用层协议。这样小明就完成了从不可靠、不安全的一层到应用层，可靠又安全的五层协议。最后小明如愿的像小红表了白。至于小明有没有和小红在没在一起，那我不知道了。这也就是我们后来所熟知的OSI（网络七层协议模型）在七层协议中会有两层会被淡化，所以我们这里只讨论五层协议。不可靠丢包，重复包出错（只能通过重传来解决）乱序不安全容易被窃取信息（在网络层，通过路由打电话，随时都可能被黑客监听）窃取篡改文末本章节主要介绍了OSI（网络七层协议模型）如有不对的地方还望大家在下方留言欢迎关注公众号：Coder编程获取最新原创技术文章和相关免费学习资料，随时随地学习技术知识！Github个人主页目录Gitee个人主页目录参考文章：https://www.cnblogs.com/carlo…https://blog.csdn.net/taotong…

前言在复杂的网络通信中,网络交互在线路上产生巨大流量,由于设备性能的差异和缺陷,网络中发生像高速公路的拥塞也是很正常的,为了减少网络中数据拥塞和丢失所造成的损失,因此网络协议中采用了流量控制和拥塞控制技术.辨析流量控制:流量控制主要由通信双方设备决定,具体为发送方发送窗口和接收方接收窗口决定.一般地,发送窗口会有一定的数据缓存,所以发送方并不能发送最大窗口值数据,而接收方的接受窗口也可能存在数据缓存,于是这两个窗口决定了发送方所发送的数据量,因此称之为流量控制.拥塞控制:拥塞控制没有那么明确,总的来讲,除开发送端和接收端,其中间网络设备的通信能力,就像一个黑盒子,我们知道接收方返回的确认信息越来越慢,于是我们就猜测其中拥塞程度变大了.这就是网络出现了拥塞.流量控制首先,流量控制涉及四个窗口,即发送方和接收方各有两个(发送窗口,接收窗口),所以流量通信是四个窗口,并不是我们想象中的两个窗口哦,如图:流量控制具体流程假设窗口大小为300字节,此时已发送出序号101开始的300字节数据,窗口在框1处.假设此时接收到了接收方的确认ack=301,且窗口大小为200B(流量控制起作用了,即希望下次只发送200B数据),在此,数据并未被完全接收,因此窗口只能滑动到确认号为301的位置.如图中框2,所以窗口中的101,201缓存即被删除.此时待发数据为401和501.此时收到接收方的确认ack=601,窗口300,即窗口滑动向601,如图窗口3准备发送接下来的601,701,801.当发送方一直没收到确认或确认包窗口值为0时,会发送一个探测性数据段,返回窗口值为0时,启动超时计时器,到时后继续发送探测,若接收端发送来了窗口值不为0的数据段,则发送端开始正常发送数据.流量控制的两种算法Nagle算法发送端并不一有数据就发送,而是自己先把数据缓存起来,达到接收方窗口值一半或发送窗口最大值,就即刻发送.Clark算法接收端让发送方等待,当自己由足够的接收窗口空间时,再发送确认信息.在流量控制中,这两种算法十分重要,并且是结合使用的.TCP拥塞控制TCP拥塞控制主要依靠TCP连接双方协定的协议来减少数据的发送儿实现的.进入网络的数据大于出口时,就会发生网络拥塞.实际吞吐量和输入负荷之间的关系:1988年解决方案术语CWND:拥塞窗口大小SSTHRESH:慢启动阈值过程有一初始值SSTHRESH,并维护一拥塞窗口.慢启动:2倍速增长.拥塞避免:每次加1.阻塞后,SSTHRESH变为原来的一半.重新开始步骤2发送数据段大小:为MAX(发送窗口大小,拥塞窗口)1990年后新增方案:快速重传/快速恢复快速重传快速恢复未完待续…..

最近参与的项目中，由于使用了自签名的Https，由于之前的项目中并没有接触过Https，所以在接入之后出现了一些问题。在进行网络请求的时候抛出了如下异常。java.security.cert.CertPathValidatorException: Trust anchor for certification path not found同时在使用WebView进行装载页面的时候，也出现了页面空白的问题。借此机会，准备对Https进行一个系统的学习。从为什么要使用Https，Https的实现原理，在Android中Https的应用。为什么需要Https内容劫持上面的几个图，在平时我们使用手机的过程中是经常出现的一个现象。产生上述问题的原因是我们在数据传输的时候通过http进行传输导致了被运营商劫持，然后修改了其中的内容。敏感数据同时也会有一些个人开启wifi，然后对其中内容做嗅探，获取其中的敏感数据。为了提升用户体验，采用Https是一个不错的方式，相比于采用自己的协议方便很多。补充知识Https是什么？HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS的主要思想是在不安全的网络上创建一安全信道，并可在使用适当的加密包和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的防护。SSL协议在通信过程中起了两个作用：1、确保通信双方身份没有伪造，通过数字证书实现。2、确保与服务器之间的通讯不能被第三方窃取、修改。了解https通信过程还需知道两种加密方式：非对称加密和对称加密。客户端与服务器进行安全数据交互之前，需在非对称秘钥的加密保护下生成用于会话期数据加密的对称秘钥。3.1 对称加密算法对称加密是指：加密和解密使用相同密钥的算法。它要求发送方和接收方在安全通信之前，商定一个对称密钥。对称算法的安全性完全依赖于密钥，密钥泄漏就意味着任何人都可以对他们发送或接收的消息解密，所以密钥的保密性对通信至关重要。3.1.1 对称加密又分为两种模式：流加密和分组加密流加密是将消息作为字节流对待，并且使用数学函数分别作用在每一个字节位上。使用流加密时，每加密一次，相同的明文位会转换成不同的密文位。流加密使用了密钥流生成器，它生成的字节流与明文字节流进行异或，从而生成密文。分组加密是将消息划分为若干个分组，这些分组随后会通过数学函数进行处理，每次一个分组。假设使用64位的分组密码，此时如果消息长度为640位，就会被划分成10个64位的分组（如果最后一个分组长度不到64，则用0补齐之后加到64位），每个分组都用一系列数学公式进行处理，最后得到10个加密文本分组。然后，将这条密文消息发送给对端。对端必须拥有相同的分组密码，以相反的顺序对10个密文分组使用前面的算法解密，最终得到明文消息。比较常用的分组加密算法有DES、3DES、AES。其中DES是比较老的加密算法，现在已经被证明不安全。而3DES是一个过渡的加密算法，相当于在DES基础上进行三重运算来提高安全性，但其本质上还是和DES算法一致。而AES是DES算法的替代算法，是现在最安全的对称加密算法之一。3.1.2 对称加密算法的优缺点：优点：计算量小、加密速度快、加密效率高。缺点：（1）交易双方都使用同样密钥，安全性得不到保证；（2）每次使用对称加密算法时，都需要使用其他人不知道的惟一密钥，这会使得发收信息双方所拥有的钥匙数量呈几何级数增长，密钥管理成为负担。在非对称密钥交换算法出现以前，对称加密的最主要缺陷就是不知道如何在通信双方之间传输对称密钥，而又不让中间人窃取。非对称密钥交换算法诞生之后，专门针对对称密钥传输做加解密，使得对称密钥的交互传输变得非常安全了。非对称密钥交换算法本身非常复杂，密钥交换过程涉及到随机数生成，模指数运算，空白补齐，加密，签名等等一系列极其复杂的过程，作者本人也没有研究完全透彻。常见的密钥交换算法有RSA，ECDHE，DH，DHE等算法。涉及到比较复杂的数学问题。其中，最经典也是最常用的是RSA算法。3.2.1 非对称加密相比对称加密更加安全，但也存在两个致命的缺点：（1）CPU计算资源消耗非常大。一次完全TLS握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%。如果后续的应用层数据传输过程也使用非对称加解密，那么CPU性能开销太庞大，服务器是根本无法承受的。赛门特克给出的实验数据显示，加解密同等数量的文件，非对称算法消耗的CPU资源是对称算法的1000倍以上。（2）非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。所以非对称加解密（极端消耗CPU资源）目前只能用来作对称密钥交换或者CA签名，不适合用来做应用层内容传输的加解密。SSL介绍：安全套接字（Secure Socket Layer，SSL）协议是Web浏览器与Web服务器之间安全交换信息的协议，提供两个基本的安全服务：鉴别与保密。SSL是Netscape于1994年开发的，后来成为了世界上最著名的web安全机制，所有主要的浏览器都支持SSL协议目前有三个版本：2、3、3.1，最常用的是第3版，是1995年发布的。SSL协议的三个特性① 保密：在握手协议中定义了会话密钥后，所有的消息都被加密。② 鉴别：可选的客户端认证，和强制的服务器端认证。③ 完整性：传送的消息包括消息完整性检查（使用MAC）。SSL的位置SSL介于应用层和TCP层之间。应用层数据不再直接传递给传输层，而是传递给SSL层，SSL层对从应用层收到的数据进行加密，并增加自己的SSL头。Https建立过程？SSL连接建立过程客户端和服务器交换数据之前有个握手协议，具体过程是：1、客户端初始化支持的加密算法、压缩算法、SSL协议版本，并向服务器发起消息结构体为client hello的连接2、服务端收到消息，根据客户端提供的加密算法列表、压缩算法列表来选取后续使用的对称加密算法、压缩算法和SSL协议版本，并返回结构体为server hello的消息。3、如果客户端需要服务器身份认证，服务器在返回server hello的消息后需立刻返回数字证书信息（通常服务器认证是必须的），并发送hello done的消息。4、客户端验证证书是否有效，并发送用证书公钥加密的对称秘钥。5、服务器收到加密的对称秘钥，使用自己的私钥解密，并发送通过对称秘钥加密的的会话完成信息 （finish信息）。证书校验过程颁发证书的机构会将证书内容使用指定的哈希函数生成内容hash，然后用自己的私钥加密哈希形成签名。证书指纹用于确定证书没有被修改。解密验证过程如上右图，如果最终得到的签名与客户端使用指定的签名算法得到的签名不一致，则证书是不可信的。参考资料Android安全开发之安全使用HTTPShttps通信原理

概述@Copyright图片版权归笔者所有,转载请告知.目的这篇文章能帮助大家快速回忆计算机网络体系,当然短短的文章并不能深入表述,文章并未涉及网络层和数据链路层,重点叙述了传输层.可能有所不足或错误,也谢谢大家指出,共同进步结构体系简述计算机网络协议体系结构目前有两种,一种是OSI/RM七层协议,另一种则是TCP/IP协议体系,两种体系结构对计算机网络分别划分了7和5个层次,OSI/RM是一种参考协议,当前用的主要还是TCP/IP体系.TCP/IP概述TCP/IP协议族按照层次由上到下，层层包装。顶层是应用层，里面有http，ftp,等等我们熟悉的协议。第二层则是传输层，著名的TCP和UDP协议就在这个层次。第三层是网络层，IP协议就在这里，它负责对数据加上IP地址和其他的数据以确定传输的目标。第四层是叫数据链路层，这个层次为待传送的数据加入一个以太网协议头，并进行CRC编码，为最后的数据传输做准备。再往下则是物理层了，负责网络的传输，这个层次的定义包括网线的制式，网卡的定义等等,这不是我们关注的部分,它几乎和tcp/ip协议的编写者没有任何的关系。发送协议的主机从上自下将数据按照协议封装，而接收数据的主机则按照协议从得到的数据包解开，最后拿到需要的数据。这种结构非常有栈的味道，所以也把tcp/ip协议族称为tcp/ip协议栈。详述应用层在应用层包含了不同类型的应用进程，如：telnet远程登录、FTP文件传输,qq聊天等,计算机应用直接接触的协议都放在应用层里,需要通信时,将应用层的信息按照应用层所对应的协议编写,传向下一层.例如http协议,可以初略的理解成编写成文本后通过传输层发送.如下测试图,给大家参考下.传输层传输层主要为两台主机上的应用程序提供端到端的通信服务。在TCP/IP协议族中，有两个不同的传输协议：TCP（传输控制协议）和UDP（用户数据报协议）。TCP:为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小数据块（数据段）交给下面的网络层，确认接收到的分组，设置发送最后确认分组的超时时间等。由于传输层提供了高可靠性的端到端的通信服务，因此应用层可以忽略掉所有这些细节。UDP:为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。任何必需的可靠性必须由应用层来提供。这两种传输层协议分别在不同的网络环境与应用场合中有不同的用途。功能TCP和UDP采用16 bit的端口号来识别不同的应用程序。网络服务一般都是通过知名端口号来识别的。知名的1～1023之间的端口号由Internet号码分配机构（Internet Assigned Numbers Authority, IANA）来管理。现在IANA管理1～1023之间所有的端口号。大多数TCP/IP实现给临时端口分配1024～5000之间的端口号。大于5000的端口号是为其他服务（Internet上并不常用的服务）预留的。应用程序FTPTELNETHTTPHTTPS熟知端口号212380443如果仔细检查这些标准的简单服务以及其他标准的TCP/IP服务（如Telnet、FTP、SMTP等）的端口号时，我们发现它们都是奇数。这是因为这些端口号都是从NCP端口号派生出来的（NCP，即网络控制协议，是ARPANET的传输层协议，是TCP的前身）。NCP是单工的，不是全双工的，因此每个应用程序需要两个连接，需预留一对奇数和偶数端口号。当TCP和UDP成为标准的传输层协议时，每个应用程序只需要一个端口号，因此就使用了NCP中的奇数。TCP传输控制协议先来一张亲手绘制的美图如上,便是一个tcp数据段的数据结构图关键名词介绍序号:每个数据段中的数据部分中的每个字节都有一个序号,而当前数据段的序号则为第一个字节的序号.确认号:希望对方传过来的下一数据段的序号.窗口大小:表示本端可以接收的数据量,该量只针对数据部分的数据大小.数据偏移:因为数据段中存在可选项,因此并不知道真正的数据是从哪儿开始的,因此数据偏移记录了数据的其实位置.URG:紧急ACK:表示响应RSH:表示有数据传输RST:表示连接重置SYN:表示建立连接FIN:表示关闭连接三次握手和四次挥手先来一张三次握手图1.客户端说我要连接你,于是把请求连接的SYN字段置为1,序列号为n的清量请求数据段发送给接收方.2.接收方收到后,发送了一个请求连接字段SYN和确认字段ACK置为1,序号为m,确认号为n+1(表示我刚刚收到你的数据段序号为n,下面我希望收到n+1的数据段)的数据段给发送方.3,发起连接的一方收到确认信息后,对此确认信息进行确认,于是发送了序号为n+1,确认号为m+1的确认轻量级数据段进行确认.4.接收方收到确认信息后,此端到端的通信即创建成功.注意在请求连接时,可能会由于某种原因造成请求连接的数据中断.此时接收方有超时机制,避免长时间忙等.超时重传机制将在另外一篇文章中完整展开.若两方同时发起连接请求,此时双方互为发送方和接收方,通信依然能正常建立.四次挥手图1.客户端发起关闭连接的请求,于是发送FIN字段置为1,序号为n的数据段.2.服务端收到请求后,发送了ACK字段为1,序号为m的数据段,因为关闭客户端发送数据的连接,所以服务端不需要再收到确认了,因此无需发送确认号.3.当服务端认为自己数据传输完成了,于是发起FIN字段为1,序号为1,确认号为n+1的数据段,因为上一次客户端发送的是序号n,所以此次请求希望收到n+1的数据段.客户端收到关闭请求后,发送确认数据段.注:1.以上 称服务端和客户端有些许绝对,只是方便描述,其实可以看做发送端和接收端,即平级的.2.关闭连接也可能发生数据段丢失,因此也会引入超时重传机制.附:名词详解SYN:TCP连接的第一个包，非常小的一种数据包。 TCP首部的数据格式，如果不计任选字段，它通常是20个字节。 每个TCP段都包含源端和目的端的端口号，用于寻找发端和收端应用进程。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接。序号:用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。序号是32 bit的无符号数。当建立一个新的连接时，SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN（Initial Sequence Number）。因为SYN标志消耗了一个序号，该主机要发送数据的第一个字节序号为这个ISN加1。确认序:号包含发送确认的一端所期望收到的下一个序号。确认序号应当是上次已成功收到数据字节序号加1。只有ACK标志为1时确认序号字段才有效。发送ACK无需任何额外代价，因为32 bit的确认序号字段和ACK标志一样，总是TCP首部的一部分。因此，我们看到一旦一个连接建立起来，这个字段总是被设置，ACK标志也总是被设置为1。TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据序号。在TCP首部中有6个code bits 中的多个可同时被设置为1。含义如下：URG紧急指针（urgent pointer）有效. ACK确认序号有效。 PSH接收方应该尽快将这个报文段交给应用层。 RST重建连接。 SYN同步序号用来发起一个连接。 FIN发端完成发送任务。TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，窗口大小是一个16 bit字段，因而窗口大小最大为65535bit数据即8KB。检验和覆盖了整个的TCP报文段：包括了TCP首部和TCP数据。这是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。最常见的可选字段是最长报文大小，又称为MSS (Maximum Segment Size)。每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志的那个段）中指明这个选项。它指明本端所能接收的最大长度的报文段。TCP报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有TCP首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

IXP：Internet Exchange Point。ISP POP 连接到 Internet 交换点 (IXP)，不同的 ISP 在 IXP 汇聚，从而接入对方的网络并交换信息。通过 IXP 和私有对等连接互连的网络共同组成了 Internet 主干。（维基百科）IXP的主要目的是实现网络直连，主要好处在于带宽、速度和花费（图源：https://blog.csdn.net/flowing…）国内IXP应用不强，美国较强。国内主流电信运营商之间互联主要采用直连模式。Kang的Practical Verifiable In-network Filtering for DDoS defense提议在上游IXPS部署filters来完成攻击过滤，对从中国发起的DDoS攻击不适用。互联网服务供应商（英语：Internet Service Provider，简称ISP），又称因特网服务提供者、互联网服务提供商、网络服务供应商，即指提供互联网存取服务的公司。通常大型的电讯公司都会兼任互联网服务供应商，一些ISP则独立于电信公司之外。（百度百科）A point of presence (PoP) is an artificial demarcation point or interface point between communicating entities. A common example is an Internet point of presence, the local access point that allows users to connect to the Internet with their Internet service provider (ISP).[1] A PoP typically houses servers, routers, network switches, multiplexers, and other network interface equipment, and is typically located in a data center. ISPs typically have multiple PoPs. PoPs are often located at Internet exchange points and colocation centres.[2]（维基百科）POP：point-of-present。计算机和企业网络通过出现点（POP）连接到ISP，POP位于ISP网络的边缘，仅为特定地域提供服务。POP能够为多个最终用户提供本地接入点和身份验证（密码控制）。（百度百科）互联网数据中心（Internet Data Center）简称IDC，就是电信部门利用已有的互联网通信线路、带宽资源，建立标准化的电信专业级机房环境，为企业、政府提供服务器托管、租用以及相关增值等方面的全方位服务。（百度百科）边界网关协议（英文：Border Gateway Protocol, BGP）是互联网上一个核心的去中心化自治路由协议。它通过维护IP路由表或‘前缀’表来实现自治系统（AS）之间的可达性，属于矢量路由协议。BGP不使用传统的内部网关协议（IGP）的指标，而使用基于路径、网络策略或规则集来决定路由。因此，它更适合被称为矢量性协议，而不是路由协议。在路由协议中，只有BGP使用TCP作为传输层协议。同一个AS自治系统中的两个或多个对等实体之间运行的BGP被称为IBGP（Internal/Interior BGP）（维基百科）AS（Autonomous system）：自治系统，指在一个（有时是多个）组织管辖下的所有IP网络和路由器的全体，它们对互联网执行共同的路由策略。也就是说，对于互联网来说，一个AS是一个独立的整体网络。而BGP实现的网络自治也是指各个AS自治。每个AS有自己唯一的编号。IGP（Interior Gateway Protocol）：内部网关协议，在一个AS内部所使用的一种路由协议。一个AS内部也可以有多个路由器管理多个网络。各个路由器之间需要路由信息以知道子网络的可达信息。IGP就是用来管理这些路由。代表的实现有RIP和OSPF。BGP是一种路径矢量协议（Path vector protocol）的实现。因此，它的工作原理也是基于路径矢量。首先说明一下，下面说的BGP route指的是BGP自己维护的路由信息，区分于设备的主路由表，也就是我们平常看见的那个路由表。BGP route是BGP协议传输的数据，并存储在BGP router的数据库中。并非所有的BGP route都会写到主路由表。每条BGP route都包含了目的网络，下一跳和完整的路径信息。路径信息是由AS号组成，当BGP router收到了一条 路由信息，如果里面的路径包含了自己的AS号，那它就能判定这是一条自己曾经发出的路由信息，收到的这条路由信息会被丢弃。这里把每个BGP服务的实体叫做BGP router，而与BGP router连接的对端叫BGP peer。每个BGP router在收到了peer传来的路由信息，会存储在自己的数据库，前面说过，路由信息包含很多其他的信息，BGP router会根据自己本地的policy结合路由信息中的内容判断，如果路由信息符合本地policy，BGP router会修改自己的主路由表。本地的policy可以有很多，举个例子，如果BGP router收到两条路由信息，目的网络一样，但是路径不一样，一个是AS1->AS3->AS5，另一个是AS1->AS2，如果没有其他的特殊policy，BGP router会选用AS1->AS2这条路由信息。policy还有很多其他的，可以实现复杂的控制。除了修改主路由表，BGP router还会修改这条路由信息，将自己的AS号加在BGP数据中，将下一跳改为自己，并且将自己加在路径信息里。在这之后，这条消息会继续向别的BGP peer发送。而其他的BGP peer就知道了，可以通过指定下一跳到当前BGP router，来达到目的网络地址。所以说，BGP更像是一个可达协议，可达信息传来传去，本地根据收到的信息判断决策，再应用到路由表。（引用：https://zhuanlan.zhihu.com/p/…）Round-trip time (RTT) is the duration in milliseconds (ms) it takes for a network request to go from a starting point to a destination and back again to the starting point. (引用：https://www.cloudflare.com/le…） ...

博客原文地址：https://godbmw.com/passages/2019-03-02-gpsr/博客主题推荐：Theme Art Design，“笔记记录+搭建知识体系”的利器。这是之前学习《无线传感网络》这门课做的期末大作业，GPSR是"greedy perimeter stateless routing"的缩写。这是一种无状态的路由转发协议，巧妙地借助“贪婪转发”和“周边转发”有效地降低了每个物理节点的存储信息量，非常具有实用意义。除此之外，它还能快速地应对现实中外界条件、节点能耗等多种因素造成的频繁变化的节点分布。因此，特别重温一下，作为一次分享。0. 摘要随着路由节点的增加以及拓扑结构变化率的增大，传统的路由转发协议算法效率低、鲁棒性差。贪婪周界无状态路由协议(GPSR)只使用拓扑结构中的临近信息节点进行“贪婪转发”决策。当数据包进入“路由空洞”的时候，算法会先构造GG平面图或者RNG平面图，然后采用“周边转发”绕过此区域。此过程中，算法会自动切换“贪婪转发”和“周边转发”这两种模式。在频繁变化或者节点数量多的拓扑结构中，并且每个节点存储的信息量少，GPSR可以较低的成本快速地响应变化，查询正确的路由路径。关键词：GPSR, 贪婪转发, 周边转发, 路由空洞, 平面图1. 研究背景及意义1.1 研究背景与动机当下的一些路由具有节点多、拓扑结构变化快的特点，例如：Ad-hoc网络（无基础设施，支持军事用户、灾后救援人员以及临时协作）、传感器网络（由小型传感器组成，节点资源匮乏）、“屋顶”网络（非移动，但是密集遍布大都市区域，节点数量数十万）。传统的路由算法的节点成本和消息成本过高，造成在高移动性和密集节点拓扑结构中的的低适应性。因此，需要一种新的节点成本低、鲁棒性高的路由算法。1.2 研究意义论文提出的GPSR算法合理利用地理信息来实现高稳健性。在网络节点数量不断增加的情况下提高稳健性和迁移率，降低路由协议消息发送成本，各个路由节点消息传递成功率以及使得每个节点存储最少的信息量。2. 国内外研究现状论文中提出的DV和LS算法，要求将整个网络拓扑结构的映射到所有的路由节点。在DV算法的描述中，每个路由节点都记录了最新周期中到所有网络目的地的距离；在LS算法的描述中，每个路由节点都会接受到链路改变的相关信息状态。当拓扑结构变化率增大，或者路由区域中的路由节点的数量增多，DV算法和LS算法的复杂度就会增加，同时增加的还有每个节点的信息量储备和节点之间沟通成本。虽然“缓存”技术可以减少节点负载，但是当节点数目过多或者拓扑结构变化率过大的时候，现有算法仍然不能保证较高的鲁棒性以及较低的节点开销。3. 研究内容3.1 主要挑战及创新点为了让节点存储最少的信息量，并且能够快速响应拓扑结构的变化。需要使用贪心法的思想，让每一步都是最优解，这个转发过程就是“贪心转发”。但是有些时候无法满足“贪心转发”的条件，此时的情况就是“路由空洞”。解决“路由空洞”的重要技术是“右手法则”，这个转发过程就是“周边转发”。而在周边转发之前需要将图处理成平面图，有GG和RNG两种平面图供选择。在转发过程中，根据节点条件，切换“贪心转发”模式和“周边转发”模式，直到到达最终的目的节点。3.2 相关技术介绍GPSR算法的实现过程中，需要配合“信标算法”来确定邻居节点的位置信息。“信标算法”中，每个节点周期性的以广播方式传送一个信标，信标包括节点自身的位置信息，位置信息被编码成两个4字节的浮点数值，用于标记节点的x坐标和y坐标。数据格式是(IP, (x, y))。为了避免邻居节点发送的信标产生冲突，用B表示信标间的时间间隔，节点发送信标的时间统一分布在[0.5B, 1.5B]之间。设节点保留位置信息的最长时间为T，在超过T时间间隔后仍然没有收到邻居节点发送的信标，就认为邻居节点失效或超出覆盖范围，删除对应的位置信息。借助这些地理信息，GPSR算法的可以避免探测包的盲目洪泛，从而进行有效的路由转发，并且针对节点变动进行有效的路由维护。甚至实现基于无状态的分布式的非端到端的数据转发。3.3 贪婪转发贪婪转发的过程是指：数据包由源节点标记要发送数据包的目标节点或目标区域位置；每一个中间的转发节点都知道它的邻居节点的位置，转发节点在选择数据包的下一跳节点时使用贪婪转发策略，即选择地理位置最接近目标节点的节点作为下一跳节点；以此类推，每一次转发都会更加接近目标节点，直至到达目标节点。贪婪转发的原理就是利用“贪心”思想，让每个节点选择当前的最优选择（在满足条件的情况下），直到算法结束。如下图所示，根据贪婪转发的原则，节点x的下一跳节点就是节点y。毫无疑问，贪婪转发只需要保证节点的一条邻居信息即可。3.3 贪婪转发困境·路由空洞路由空洞是指当前节点比所有其他一跳邻居节点更接近目的节点，此时，根据贪婪转发的规则，当前节点不会转发数据给一跳的邻居节点。如果存在这种网络拓扑结构，那么就称之为“路由空洞”。如下图所示，void区域就是没有满足“贪婪转发”条件的区域。因为节点x的覆盖范围与以直线xD为半径的圆的交叉区域没有邻居节点。3.4 周边转发针对上述的“路由空洞”问题，算法会将模式（Mode）从贪婪转发切换到周边转发，进而绕过“路由空洞”。“周边转发”是根据“右手法则”来判断下一跳转节点：连接当前节点和目的结点形成直线，右手握住此线逆时针旋转，到达的第一条边（边代表其上的两个点可以互达）就是下一跳的方向。3.5 周边转发困境虽然周边转发可以绕过“路由空洞”，但在一些情况下，单纯地进行周边转发可能会陷入死循环，最终只能回到当前节点，无法抵达目的节点。这里举一个例子进行介绍。下图是一个由X、W、U、Z以及目的节点D构成的图，节点之间的连线代表着两端节点是相邻的（可以互相达到）。假设现在从节点X开始出发。从X节点开始，根据“右手法则”依次抵达U节点、Z节点和W节点。此时，对W节点再次使用“右手法则”，算法又重新跳回了U节点。最后，对U节点使用“右手法则”，跳回了开始节点X。显而易见，此时的周边转发陷入困境。这主要是由于这张图不是一个“平面图”的原因。需要删除一些边，从而使其变成GG或者RNG平面图，才能走出此困境。3.6 RNG平面图和GG平面图RNG平面图的定义是：若顶点U，V和任意其它顶点W之间的距离，全都大于或等于顶点u和v之间的距离d(u，v)，则在顶点U和V之间存在RNG边(u，v)。用方程式表示如下:如下图所示，若(u，v)是RNG中的边，则在节点U和V之间的阴影半月形区域内，不能包含有任何证明节点w。此时，由于d(u, v) > max(d(u,w), d(w,v)),为了构建RNG平面图，必须把边(u, v) 舍去。关于RNG平面实现的伪代码如下。其中，N是对于任意节点u来说的邻接节点列表，v是集合N中的任一节点。GG平面图的定义是：如果节点u和节点v之间，直径为uv的圆内，不存在其它顶点W，则节点u和节点v存在GG边(u，v)。用方程式表示如下:如下图所示，若(u，v)是GG中的边，则在节点U和V之间的圆形阴影区域，不能包含有任何证明节点w。关于GG平面实现的伪代码如下。其中，N是对于任意节点u来说的邻接节点列表，v是集合N中的任一节点。对于GG和RNG两种平面图，RNG平面图是GG平面图的子集。它们之间的直接关系可以用下图表示出来：3.7 周边转发困境·RNG平面图解决构造上述的RNG平面图或者GG平面图就可以解决“周边转发”无法到达目的节点的困境。这里以构造RNG平面图为例，还是使用之前的图形。为了方便讲述，规定边xu长度为12，边xw长度为11，边uw长度为10。根据RNG的定义，D(U, X) > MAX(D(W, U), D(X, W))，所以移除UX边。此时，“周边转发”不再会陷入困境。4. 性能评估论文为了测试算法的性能，使用了Carnegie Mellon（卡梅隆）大学的测试数据。在畅通平面上，无线仿真模型节点进行运动。节点会在指定区域内随机选择一个目标，然后在指定范围内随机选择一个速度，以此速度到达目标并且停留一段时间。这个过程模拟了拓扑结构的高迁移率以及其中的节点。下图显示了不同的B（时间间隔）的情况下，GPSR传递成功的数据包。将从B=3s降低到B=1.5S并没有带来很大成功率提高，成功率也保持在97%以上。下图比较了DSR算法和GPSR算法的节点消耗，GPSR的节点消耗远远低于DSR的节点消耗，并且随着时间推移，GPSR节点的消耗也更加稳定。因此，GPSR算法达到了设计的初衷：在迁移率高的拓扑结构中，能够保持较高的鲁棒性，并且每个节点的资源消耗都得到了改善。论文中还分节点状态、路径长度等维度进行了比较，也只是说明GPSR算法的优势。主要的性能测试还是上述的传包成功率和节点消耗，其它测试这里不再冗赘。5. 阅读心得在本次论文的学习过程中，掌握了“贪婪转发”、“周边转发”、“RNG和GG平面图”，最重要的是理解了在GPSR算法中是如何调度进行状态转化（贪婪=>周边 / 周边=>贪婪），以及如何解决“路由空洞”和“周边转发困境”。除了算法的核心部分，也触类旁空地了解了“信标算法”的实现机制以及冲突解决方法。就我个人来看，GPSR算法和论文中提及的传统算法相比，已经实现了最小化节点的保存数据（节省节点资源），并且能够利用状态切换合理应对可变性高的拓扑结构。美中不足的是“信标机制”会带来额外的开销，但是相比于每个节点保存所有节点的信息，信标机制的这点开销完全可以忽略。6. 参考在阅读论文的过程中，我查找了大量的中文和英文资料，非常有助于理解这篇论文所讲述的GPSR算法。特此系统记录一下相关资料。论文：GPSR: Greedy Perimeter Stateless Routing for Wireless NetworksYoutube Videos(印度英语)https://www.youtube.com/watch…https://www.youtube.com/watch...https://www.youtube.com/watch…百度文库讲义(从43页开始): https://wenku.baidu.com/view/…博客原文地址：https://godbmw.com/passages/2019-03-02-gpsr/博客主题推荐：Theme Art Design，“笔记记录+搭建知识体系”的利器。

你好，是我琉忆。本篇是本周（2019.2-25至3-1）的最后一篇文章。之前的文章可以关注我的“PHP面试”专栏获取，或者关注我的公众号“琉忆编程库”查看历史获取。我正在segmentfault社区送两本书：《PHP程序员面试笔试真题解析》 ，今晚（3月1日）19点开奖，欢迎参与。明天就是周末了，提前祝各位周末愉快。面试时如何给自己添金？没接触过支付功能？为此特意准备了一篇“新手零基础对接境外支付paypal”的文章，为你面试添金，关注公众号：“琉忆编程库”，回复：“pay”，我发给你。以下正文的内容来自《PHP程序员面试笔试真题解析》书籍，如果转载请保留出处：【真题1】如何利用PHP解决HTTP的无状态本质？答案：可以使用Session和Cookie记住用户，监控是否同一个用户在操作。使用Session前需要在页面使用session_start()开启Session。然后使用$_SESSION来存储Session变量。使用Cookie时，需使用set_cookie()设置Cookie，然后使用$_COOKIE取Cookie值。【真题2】HTTP的Keep-Alive作用是什么？答案：HTTP的Keep-Alive作用如下：Keep-Alive使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。Web服务器基本上都支持HTTP Keep-Alive。缺点：对于提供静态内容的网站来说，这个功能通常很有用。但是，对于负担较重的网站来说，虽然为客户保留打开的连接有一定的好处，但它同样影响了性能，因为在暂停使用的期间，本来可以释放的资源仍旧被占用。所以当Web服务器和应用服务器在同一台机器上运行时，Keep-Alive功能对资源利用的影响尤其突出。解决：Keep-Alive:timeout=5,max=100timeout：过期时间5秒（对应httpd.conf里的参数是：KeepAliveTimeout），max是最多请求一百次，强制断掉连接。在timeout时间内又有新的连接过来时，max会自动减1，直到为0，强制断掉。【真题3】如何快速下载一个远程HTTP服务器上的图片文件到本地？答案：先通过fopen()函数打开要下载的图片路径，然后使用fread()函数读取图片，再在本地打开指定存储图片的目录，将读取到的图片信息写入到该目录内的文件中，即可远程下载一个图片到本地。实现代码如下：<?php $file=“http://static.nipic.com/images/originalNewtip.png"; $fp=fopen($file,‘rb’); $img=fread($fp,100000); $dir=”./"; $local=fopen($dir.’/’.basename($file),‘w’); fwrite($local,$img);?>【真题4】请简述HTTP中POST、GET、PUT、DELETE方式的区别。答案：HTTP定义了与服务器交互的不同的方法，最基本的方法是POST、GET、PUT和DELETE，URL全称是资源描述符，可以认为一个URL地址用于描述一个网络上的资源，而对应的HTTP中的四种方法GET、POST、PUT、DELETE对应这个资源的查，改，增，删四个操作。它们的具体功能为：（1）根据HTTP规范，GET用于信息获取，信息应该是安全的；（2）根据HTTP规范，POST表示可以修改服务器上的资源的请求；（3）PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器决定；（4）DELETE的功能是删除某一个资源。【真题5】如何理解HTTP的gzip压缩传输？答案：HTTP下的gzip是一种流行的文件压缩算法，在Linux平台上使用十分广泛，gzip压缩传输能更加有效节约带宽流量。它先把文本压缩为.gz然后传输给浏览器，最后由浏览器负责解压缩呈现给用户，可以降低网络传输的字节数，加快网页的加载速度。面试时如何给自己添金？没接触过支付功能？为此特意准备了一篇“新手零基础对接境外支付paypal”的文章，为你面试添金，关注公众号：“琉忆编程库”，回复：“pay”，我发给你。【真题6】如何给动态文件（如PHP页面）做缓存？（即第二次刷新浏览器时，返回304状态）答案：304状态的意思是当客户端向服务端请求时，服务端告诉客户端缓存的文档没有过期可以继续使用。可以通过以下方法作浏览器缓存：（1）当用户首次请求该文件的时候，通过HTTP HEAD的Last-Modified字段将该文件的最后修改日期发送到客户端，让客户端知道该文件的版本，例如：Last-Modified: Tue, 08 Apr 2008 14:48:05 GMT（2）在浏览器再次请求该文件的时候，会自动将该时间作为请求的HTTP HEAD的If-Modified-Since字段内容，例如：　If-Modified-Since: Tue, 08 Apr 2008 14:48:05 GMT（3）服务端根据If-Modified-Since字段的内容(如果存在该字段)来判断客户端的文件是否已经过期，如果已经过期，那么重新返回新的文件，如果没有，那么只需要返回304状态码，就可结束输出，这样代表浏览器端的文件版本是最新的，不需要返回文件内容。【真题7】真题478、请写出HTTP和HTTPS的区别。【真题8】IP是否可以伪造？PHP中如何拿到真实IP？答案：IP地址是可以伪造的，客户端可以伪造IP地址或使用代理IP导致IP地址不是用户的真实IP地址。REMOTE_ADDR代表客户端的IP地址，HTTP_X_FORWARDED_FOR是代理服务器的IP地址，存放真实的IP和各级代理IP。实现代码如下：<?php function getIP(){ $unknown = ‘unknown’; if(isset($_SERVER[‘HTTP_X_FORWARDED_FOR’])&&$_SERVER[‘HTTP_X_FORWARDED_FOR’]&&strcasecmp($_SERVER[‘HTTP_X_FORWARDED_FOR’],$unknown)){ $IP = $_SERVER[‘HTTP_X_FORWARDED_FOR’]; }elseif(isset($_SERVER[‘REMOTE_ADDR’])&&$_SERVER[‘REMOTE_ADDR’]&&strcasecmp($_SERVER[‘REMOTE_ADDR’],$unknown)){ $IP = $_SERVER[‘REMOTE_ADDR’]; } if (false !== strpos($IP,’,’)) $IP = reset(explode(’,’,$IP)); return $IP; } ?>【真题9】在HTTP 1.0中，状态码 401 的含义是（ ）；如果返回“找不到文件”的提示，则可用 header 函数，其语句为（ ）。参考答案：客户端在授权头信息中没有有效的身份信息时访问受到密码保护的页面；header(“HTTP/1.0 404 Not Found”);。【真题10】下列关于HTTP协议的说法中，错误的是（ ）。A．如果本地开启了Cookie，那么每打开一个网址，HTTP请求就会把相应的Cookie传给Web服务器B．HTTP响应的状态码为301，意思是暂时地把内容转移到一个新的URL，但是老的URL还没有废除C．HTTP是一个基于请求与响应模式的、无状态的、应用层的协议，绝大多数的Web开发都是基于HTTP协议D．绝大多数的Web开发离不开Cookie，如果禁用Cookie导致Session失效，那么可以通过URL来传递sessionID参考答案：B。分析：301表示请求的网页已被永久移动到新位置而不是暂时转移内容到新的URL。所以，选项B说法错误。预告：下周（3.4-3.8）将更新PHP面试之MySQL数据库知识点，敬请期待。以上内容摘自《PHP程序员面试笔试真题解析》书籍，该书已在天猫、京东、当当等电商平台销售。更多PHP相关的面试知识、考题可以关注公众号获取：琉忆编程库对本文有什么问题或建议都可以进行留言，我将不断完善追求极致，感谢你们的支持。

简介VRRP 是 Virtual Router Redundancy Protocol 的简称，即 虚拟路由冗余协议 。原文地址：https://linux-network-programming.readthedocs.io QQ交流群：Linux网络编程，群号：183196643欢迎关注我们的公众号：小菜学编程 (coding-fan)VRRP 最早被设计来解决网关的高可用问题：我们知道，计算机进行网络通讯时，需要网关来传输网络报文。 每台机器只能配置一个网关地址，这时网关的可靠性就非常重要了。 如果网关不幸故障了，那么使用该网关的所有机器都将受影响——断网了！解决网关单点问题的思路非常直观——部署一个备用网关，在主网关故障时切换过去。然而，由于机器只能配置一个网关地址，因此每次切换网关都需要修改该配置。 这个解决方案没能做到自动化，并不优雅。这时， VRRP 应运而生！接下来，以一个简单的例子介绍 VRRP 是如何工作的：事情是这样的。这个网络部署了两台 路由 进行互备，本网络内其他机器以这两台路由为网关进行网络通讯。 两台路由的 IP 地址分别是： 192.168.1.1 以及 192.168.1.2 。 但路由并不直接通过这些地址提供转发服务，而是使用一个 虚拟地址 192.168.1.253 。 其他计算机，如 192.168.1.3 将网关地址配置为 192.168.1.253 。通过 VRRP ，两台路由互相进行 健康检查 。 当两台路由都是健康的情况下，只有主路由对外提供虚拟地址的 ARP 响应。 这时，发往虚拟地址 192.168.1.253 的流量都由主路由处理。当主路由故障时，备用路由将检测到。 这时，备用路由开始通过 ARP 协议对外通告：虚拟地址 192.168.1.253 对应的 MAC 地址是我， 被我接管了！接下来，发往虚拟地址 192.168.1.253 的流量就开始由备用路由处理了。 这时，虚拟地址 192.168.1.253 看上去就像是 漂移 到备用路由上一样。 换句话讲，网关成功进行切换，而且无需修改其他机器的网关配置！主路由恢复后，将通过类似的手段，重新拿回流量的处理权。 这部分将不再赘述。完整流程如下：两台路由互相进行健康检查；主路由对外响应虚拟地址的 ARP 请求，通告其 MAC 地址；虚拟地址网络流量被主路由处理；备用路由发现主路由故障，开始响应虚拟地址的 ARP 请求，通告其 MAC 地址；虚拟地址网络流量被备用路由处理；主路由恢复，重新响应 ARP 请求，夺回流量；备用路由发现主路由恢复，停止响应 ARP 请求，释放流量处理权；总结起来， VRRP 主要做两件事情：通过 ARP 响应 MAC 地址实现虚 IP 漂移；通过健康检查决定什么时候进行虚 IP 漂移；应用场景本质上， VRRP 是用来实现高可用的，与网关无关。我们可以将其应用于一些网络服务的高可用，如 Web 服务： 服务高可用方案有很多， VRRP 特别适用于以下场景：服务对外只能呈现为单个 IP ；同一时刻只允许一个实例对外服务；此外， VRRP 也可用于实现负载均衡设施的高可用。 应用的高可用通过负载均衡设施解决，那么负载均衡设施如何实现高可用呢？ 答案是—— VRRP ！下面是一个非常典型的例子：局限性由于 VRRP 依赖 ARP 实现 IP 漂移，因此相关机器必须在同个网络内， 不能跨网段 。订阅更新，获取更多学习资料，请关注我们的 微信公众号 ： ...

确实，从浏览器输入一个地址之后，当你按下Enter键之后，一系列奇怪的魔法就在发生，这是一个老生长谈的问题了，但能真的仔细知道全部却是一个艰难的事情。

我们今天无处不在的在使用WEB服务，网购、视频、新闻、在线学习、支付。互联网服务已经慢慢像水电煤气一样成为我们生活不可获取的一部分。这WEB服务中HTTP及相关协议是一切通信的基础，整个行业都在围绕着它来使用与服务。所以HTTP相关问题也向JavaScript基础知识一样，是不可缺少的基础知识。HTTP发展TCP/IP大学计算机网络原理一开篇就介绍了网络OSI七层模型（还有TCP/IP五层模型）：应用层会话层表示层传输层网络层数据链路层物理层如今人们在这七层上分别发展出了不同的协议，这些协议深入我们生活中。层功能协议应用层文件传输，电子邮件，文件服务，虚拟终端HTTP TFTP SNMP FTP SMTP DNS表示层数据格式化，代码转换，数据加密该层被弃用会话层解除或建立与其他节点的联系该层被弃用传输层提供端对端的接口TCP UDP SSL/TLS网络层为数据包选择路由IP ICMP RIP OSPF BGP IGMP数据链路层传输有地址的帧，错误检测功能SLIP CSLIP PPP ARP RARP MTU物理层以二进制数据形式为物理媒体上传输数据以太网 体制解调器 光导纤维 双绞线可以从表中看到TCP属于传输层，IP属于网络层。TCP: 传输控制层协议，在不可靠的传输信道之上提供可靠的服务。IP：网络地址协议，联网主机之间的路由选择和寻址功能。我们的HTTP协议就是建立在这两个协议之上的，而且这两个协议一般配套使用，所以写成TCP/IP。TCP三次握手通过概念中可以看到，在不可靠的传输信道之上提供可靠地服务，原因就在这关键的三次握手????。客户端向服务端发送一条请求，请求中包含一个随机字符序号x（SYN）。服务端收到请求后向客户端发送响应，将上一条报文中的随机序号x+1，同时生成另一个随机序号y（SYN ACK）。客户端收到请求后将上一条报文中的x和y分别加1，作为请求的回应，同时附带应用数据，建立了传输通信（ACK）。通过上面三次握手????，客户端和服务端即可确认对方是要对话的人并且神志清醒可以传输数据。TCP报文TCP报文是16进制的字节流，其首部定义了数据传输的重要信息，好比快递上的快递单。mac上借助抓包工具wireshark即可看到完整的TCP报文。HTTP 0.9 只有一行的协议1991年由Tim Berners-Lee提出，目的是支持文件传输、能够请求对超文本文档的索引搜索、格式化协商机制，以及能够把客户端引导至不同的服务器，并且构建了一个简单的原型：客户端 / 服务器、请求 / 响应协议；ASCII 协议，运行于 TCP/IP 链接之上；设计用来传输超文本文档（HTML）；服务器与客户端之间的连接在每次请求之后都会关闭。requestGET /mypage.htmlresponse<HTML>这是一个非常简单的HTML页面</HTML>可以看到这个时候的HTTP协议简单到不能再简单了，功能也十分单一，几乎没有安全性可言。HTTP 1.0 构建可扩展性1991 年到 1995 年，HTML 规范和一种新型的名叫“Web 浏览器”的软件都获得了快速发展。与此同时，面向消费者的公共互联网基础设施，也日渐兴起并迅速发展起来。人们不再满足于单调的HTML，需要多元素缤纷的互联网。终于，1996年HTTP 1.0诞生，做出了很多改变：请求可以由于多行首部字段构成；响应对象前面添加了一个响应状态行；响应对象也有自己的由换行符分隔的首部字段；响应对象不局限于超文本；服务器与客户端之间的连接在每次请求之后都会关闭。requestGET /mypage.html HTTP/1.0User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)response200 OKDate: Tue, 15 Nov 1994 08:12:31 GMTServer: CERN/3.0 libwww/2.17Content-Type: text/html<HTML> 一个包含图片的页面 <IMG SRC="/myimage.gif"></HTML>在1991-1995年，这些新扩展并没有被引入到标准中以促进协助工作，而仅仅作为一种尝试：服务器和浏览器添加这些新扩展功能，但出现了大量的互操作问题。直到1996年11月，为了解决这些问题，一份新文档（RFC 1945）被发表出来，用以描述如何操作实践这些新扩展功能。文档 RFC 1945 定义了 HTTP/1.0，RFC 还解释了很多已经被实现的其他功能：内容编码、字符集支持、多部分类型、认证、缓存、代理行为、日期格式，等等但它是狭义的，并不是官方标准。HTTP 1.1 互联网标准HTTP/1.0 多种不同的实现方式在实际运用中显得有些混乱，自1995年开始，即HTTP/1.0文档发布的下一年，就开始修订HTTP的第一个标准化版本。在1997年初，HTTP1.1 标准发布，就在HTTP/1.0 发布的几个月后。HTTP/1.1 消除了大量歧义内容并引入了多项改进：连接可以复用，节省了多次打开TCP连接加载网页文档资源的时间。增加流水线操作，允许在第一个应答被完全发送之前就发送第二个请求，以降低通信延迟。支持响应分块。引入额外的缓存控制机制。引入内容协商机制，包括语言，编码，类型等，并允许客户端和服务器之间约定以最合适的内容进行交换。感谢Host头，能够使不同域名配置在同一个IP地址的服务器上。一个典型的请求流程， 所有请求都通过一个连接实现，看起来就像这样：GET /en-US/docs/Glossary/Simple_header HTTP/1.1Host: developer.mozilla.orgUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflate, brReferer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header200 OKConnection: Keep-AliveContent-Encoding: gzipContent-Type: text/html; charset=utf-8Date: Wed, 20 Jul 2016 10:55:30 GMTEtag: “547fa7e369ef56031dd3bff2ace9fc0832eb251a"Keep-Alive: timeout=5, max=1000Last-Modified: Tue, 19 Jul 2016 00:59:33 GMTServer: ApacheTransfer-Encoding: chunkedVary: Cookie, Accept-Encoding(content)GET /static/img/header-background.png HTTP/1.1Host: developer.cdn.mozilla.netUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0Accept: */*Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflate, brReferer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header200 OKAge: 9578461Cache-Control: public, max-age=315360000Connection: keep-aliveContent-Length: 3077Content-Type: image/pngDate: Thu, 31 Mar 2016 13:34:46 GMTLast-Modified: Wed, 21 Oct 2015 18:27:50 GMTServer: Apache(image content of 3077 bytes)这个已经是最熟悉不过的了，现在绝大多数的站点都使用的是HTTP1.1协议。HTTP 2.0 改进传输性能HTTP 2.0 的主要目标是改进传输性能，实现低延迟和高吞吐量。主版本号的增加听起来像是要做大的改进，从性能角度说的确如此。但从另一方面看，HTTP 的高层协议语义并不会因为这次版本升级而受影响。所有 HTTP 首部、值，以及它们的使用场景都不会变。HTTP/2在HTTP/1.1有几处基本的不同:HTTP/2是二进制协议而不是文本协议。不再可读，也不可无障碍的手动创建，改善的优化技术现在可被实施。这是一个复用协议。并行的请求能在同一个链接中处理，移除了HTTP/1.x中顺序和阻塞的约束。压缩了headers。因为headers在一系列请求中常常是相似的，其移除了重复和传输重复数据的成本。其允许服务器在客户端缓存中填充数据，通过一个叫服务器推送的机制来提前请求。在2015年5月正式标准化后，HTTP/2取得了极大的成功，在2016年7月前，8.7%的站点已经在使用它，代表超过68%的请求。高流量的站点最迅速的普及，在数据传输上节省了可观的成本和支出。后 HTTP目前只有少部分站点支持HTTP2，但是HTTP并未停止发展，会一直扩充满足互联网需求，目前HTTP-overQUIC协议被重命名为HTTP3，具体了解可以看这里。我们在chrome中可以看到站点请求使用了那些协议，以www.taobao.com为例。HTTPS握手人们会用 Web 事务来处理一些很重要的事情。如果没有强有力的安全保证，人们就 无法安心地进行网络购物或使用银行业务。如果无法严格限制访问权限，公司就不 能将重要的文档放在 Web 服务器上。Web 需要一种安全的 HTTP 形式。目前已存在一些提供认证(基本认证和 摘要认证 )和报文完整性检查(摘要 qop=“auth-int”)的轻量级方法。对很多网络事务来说，这些方法都是很好用的， 但对大规模的购物、银行事务，或者对访问机密数据来说，并不足够强大。这些更 为重要的事务需要将 HTTP 和数字加密技术结合起来使用，才能确保安全。HTTP 的安全版本要高效、可移植且易于管理，不但能够适应不断变化的情况而且还应 该能满足社会和政府的各项要求。我们需要一种能够提供下列功能的 HTTP 安全技术。服务器认证 (客户端知道它们是在与真正的而不是伪造的服务器通话)。客户端认证 (服务器知道它们是在与真正的而不是伪造的客户端通话)。完整性 (客户端和服务器的数据不会被修改)。加密 (客户端和服务器的对话是私密的，无需担心被窃听)。效率 (一个运行的足够快的算法，以便低端的客户端和服务器使用)。普适性 (基本上所有的客户端和服务器都支持这些协议)。管理的可扩展性 (在任何地方的任何人都可以立即进行安全通信)。适应性 (能够支持当前最知名的安全方法)。在社会上的可行性 (满足社会的政治文化需要)。HTTPS现在已经被广泛应用，甚至苹果公司要求开发者在 2017 年前全部采用「HTTPS」，这里只讨论核心的建立连接过程。知识点扫盲对称/非对称加密对称密钥加密技术很多数字加密算法都被称为 对称密钥(symmetric-key) 加密技术，这是因为它们在编码时使用的密钥值和解码时 一样(e=d)。我们就将其统称为密钥 k。流行的对称密钥加密算法包括：DES、Triple-DES、RC2 和 RC4。保持密钥的机密状态是很重要的。在很多情况下，编 / 解码算法都是众所周知的，因此密钥就是唯一保密的东西了。好的加密算法会迫使攻击者试遍每一个可能的密钥，才能破解代码。用暴力去尝试 所有的密钥值称为 枚举攻击(enumeration attack)。但是这有一个致命的问题，发送者和接受者在对话之前一定要均持有保密秘钥（公钥），当有N个节点，每个节点要与其他节点进行对话的时候，就会有!N个公钥。公开密钥加密技术公开密钥加密技术没有为每对主机使用单独的加密 / 解密密钥，而是使用了两个非对称密钥：一个用来对主机报文编码，另一个用来对主机报文解码。RSA所有公开密钥非对称加密系统所面临的共同挑战是，要确保即便有人拥有了下面所有的线索，也无法计算出保密的私有密钥:公开密钥 (是公有的，所有人都可以获得);一小片拦截下来的密文 (可通过对网络的嗅探获取);一条报文及与之相关的密文 (对任意一段文本运行加密器就可以得到)。RSA算法 就是一个满足了所有这些条件的流行的公开密钥加密系统，它是在 MIT 发明的，后来由 RSA 数据安全公司将其商业化。即使有了公共密钥、任意一段明文、用公共密钥对明文编码之后得到的相关密文、RSA 算法自身，甚至 RSA 实现 的源代码，破解代码找到相应的私有密钥的难度仍相当于对一个极大的数进行质因数分解的困难程度，这种计算被认为是所有计算机科学中最难的问题之一。因此， 如果你发现了一种能够快速地将一个极大的数字分解为质因数的方法，就不仅能够入侵瑞士银行的账户系统，而且还可以获得图灵奖了。混合加密系统和会话密钥任何人只要知道了其公开密钥，就可以向一台公共服务器发送安全报文，所以非对称的公开密钥加密系统是很好用的。两个节点无须为了进行安全的通信而先交换私有密钥。但公开密钥加密算法的计算可能会很慢。实际上它混合使用了对称和非对称策略。 比如，比较常见的做法是在两节点间通过便捷的公开密钥加密技术建立起安全通信， 然后再用那条安全的通道产生并发送临时的随机对称密钥，通过更快的对称加密技 术对其余的数据进行加密。（SSH和HTTPS都是这样的）RSA算法简单解释就是：选择两个不相等的质数p，q（比如 61 13）算出pq乘积n（322）算出n的欧拉函数(n)（3120）随机选择一个整数e，条件是1< e < (n)，且e与(n) 互质（17）计算e对于(n)的模反元素d（2753）将n和e封装成公钥（3233，17），n和d封装成私钥（3233，2753）这里最关键的是d，因为n和d组成了私钥，一旦d泄漏，就等于私钥泄漏。如果n可以被因数分解，d就可以算出，也就意味着私钥被破解。可是，大整数的因数分解，是一件非常困难的事情。目前，除了暴力破解，还没有发现别的有效方法。所以RSA算法可靠性很高。有兴趣的可以看下阮一峰的博客：RSA算法原理（一）RSA算法原理（二）数字签名除了加 / 解密报文之外，还可以用加密系统对报文进行签名(sign)，以说明是谁编写的报文，同时证明报文未被篡改过。这种技术被称为数字签名(digital signing)。数字签名是附加在报文上的特殊加密校验码。数字签名通常是用 非对称公开密钥技术产生的。因为只有所有者才知道其私有密钥， 所以可以将作者的私有密钥当作一种“指纹”使用。RSA 加密系统将解码函数 D 作为签名函数使用，是因为 D 已经将私有密钥作为输入使用了。注意， 解码函数只是一个函数，因此，可以将其用于任意的输入。同样，在 RSA 加密系统中，以任意顺序 应用 D 和 E 函数时，两者都会相互抵消。因此 E(D(stuff)) = stuff，就像 D(E(stuff)) = stuff 一样。数字证书因特网上的“ID 卡”——数字证书。数字证书(通常被称作“certs”，有点像 certs 牌薄荷糖)中包含了由某个受信任组织担保的用户或公司的相关信息。数字证书中还包含一组信息，所有这些信息都是由一个官方的 证书颁发机构(CA) 以数字方式签发的。而且，数字证书通常还包括对象的公开密钥，以及对象和所用签名算法的描述性信息。任何人都可以创建一个数字证书，但并不是所有人都能够获得受人尊敬的签发 权，从而为证书信息担保，并用其私有密钥签发证书。X.509 v3证书不幸的是，数字证书没有单一的全球标准。就像不是所有印刷版 ID 卡都在同样的位 置包含了同样的信息一样，数字证书也有很多略有不同的形式。 不过好消息就是现 在使用的大多数证书都以一种标准格式—— X.509 v3，来存储它们的信息。X.509 v3 证书提供了一种标准的方式，将证书信息规范至一些可解析字段中。不同类型的证 书有不同的字段值，但大部分都遵循X.509 v3结构。基于 X.509 证书的签名有好几种，(其中)包括 Web 服务器证书、客户端电子邮件 证书、软件代码签名证书和证书颁发机构证书。通过 HTTPS 建立了一个安全 Web 事务之后，现代的浏览器都会自动获取所连接服 务器的数字证书。如果服务器没有证书，安全连接就会失败。浏览器收到证书时会对签名颁发机构进行检查。如果这个机构是个很有权威的公共签名机构，浏览器可能已经知道其公开密钥了(浏览器会预先安装很多签名颁发机构的证书)。如果对签名颁发机构一无所知，浏览器就无法确定是否应该信任这个签名颁发机构， 它通常会向用户显示一个对话框，看看他是否相信这个签名发布者。签名发布者可 能是本地的 IT 部门或软件厂商。SSL/TLSSSL（Secure Sockets Layer，安全套接字层）协议最初是网景公司为了保障网上交易安全而开发的，该协议通过加密来保护客户个人资料，通过认证和完整性检查来确保交易安全。为达到这个目标，SSL 协议在直接位于 TCP 上一层的应用层被实现SSL 不会影响上层协议（如 HTTP、电子邮件、即时通讯），但能够保证上层协议的网络通信安全。在正确使用 SSL 的情况下，第三方监听者只能推断出连接的端点、加密类型，以及发送数据的频率和大致数量，不能实际读取或修改任何数据。SSL 2.0 是该协议第一个公开发布的版本，但由于存在很多安全缺陷很快就被 SSL3.0 取代。鉴于 SSL 协议是网景公司专有的，IETF 成立了一个小组负责标准化该协议，后来就有了 RFC 2246，即 TLS 1.0，也就是 SSL 3.0 的升级版。TLS 1.0 自 1999 年 1 月发布后，为解决发现的安全缺陷同时扩展协议的功能，IETF工作组先后又发布过两个新版本：2006 年 4 月发布了 TLS 1.1，2008 年 8 月发布了TLS 1.2。从内部来看，SSL 3.0 实现与后续所有 TLS 版本很相似，很多客户端到今天还在支持 SSL 3.0 和 TLS 1.0。简单来说网景公司的SSL 3.0 之后更新的版本被IETF小组采纳并发布成为TLS 1.0，两者差距不明显（加密算法），但是TLS后续会继续迭代，而SSL不会。安全信道特性数据保密性信息加密就是把明码的输入文件用加密算法转换成加密的文件以实现数据的保密。加密的过程需要用到密钥来加密数据然后再解密。没有了密钥，就无法解开加密的数据。数据加密之后，只有密钥要用一个安全的方法传送。加密过的数据可以公开地传送。数据完整性加密也能保证数据的一致性。例如：消息验证码（MAC），能够校验用户提供的加密信息，接收者可以用MAC来校验加密数据，保证数据在传输过程中没有被篡改过。安全验证加密的另外一个用途是用来作为个人的标识，用户的密钥可以作为他的安全验证的标识。SSL是利用公开密钥的加密技术（RSA）来作为用户端与服务器端在传送机密资料时的加密通讯协定。OpenSSL包含一个命令行工具用来完成OpenSSL库中的所有功能，更好的是，它可能已经安装到你的系统中了。OpenSSL是一个强大的安全套接字层密码库，Apache使用它加密HTTPS，OpenSSH使用它加密SSH，但是，你不应该只将其作为一个库来使用，它还是一个多用途的、跨平台的密码工具。HTTPS握手????细节RSA握手RSA握手过程：Client Hello：客户端向服务端发送请求，请求里面包括客户端随机数（Client random）支持的协议版本（SSL/TLS）加密套件等（OpenSSL等）。Server Hello：服务端收到请求，保存客户端随机数（Server random），生成服务端随机数（Server random）以及选择加密方式并且将数字证书一同返回给客户端。Client Key Exchange：客户端收到请求保存服务端随机数（Server random），验证证书并获取到服务端公钥，之后根据前两个随机数生成一个新的随机数（Premaster secret），然后用公钥将这个随机数加密发送给服务端。这时客户端已获得了3个随机数，将3个随机数使用第二步中约定的加密方法加密，生成之后传输的对话秘钥（Session key）。Finished：服务端收到请求使用私钥解密出随机数（Premaster secret），这时服务端也获得了全部3个随机数，同样生成对话秘钥（Session key）。然后从此之后的内容都使用对话秘钥进行加密与解密（对称加密）。最后服务器返回一个加密的"Finished"消息给客户端。Application data：客户端用它之前生成的对话密钥（Session key）解密这条消息，验证 MAC，如果一切顺利，则建立信道并开始发送应用数据。抓包分析RSA握手过程：可以清晰地看到加密的握手过程，以及加密完成之后，应用数据抓包工具不再可以解析的出来。DH握手DH握手是在上文RSA基础上，修改了Premaster secret传输方式基础上完成的。其依赖的是DH密钥协商算法：不再明文传输Premaster secret，只需要传输DH参数（p, q）双方即可算出Premaster secret。DH握手过程：Client Hello：客户端向服务端发送请求，请求里面包括客户端随机数（Client random）支持的协议版本（SSL/TLS）加密套件等（OpenSSL等）。Server Hello：a. 服务端收到请求，保存客户端随机数（Server random），生成服务端随机数（Server random）以及选择加密方式并且将数字证书一同返回给客户端。b. 服务端根据Client random和Server random以及Server DH parameter通过私钥算出签名。Server Key Exchange：服务端向客户端发送DH参数以及服务端签名。Client Key Exchange：客户端验证签名之后，向服务端发送Client DH parameter。Application data：服务端收到Client DH parameter，此时双方都已有DHparameter，通过DH算法算出Premaster secret，然后将Client random和Server random以及Premaster secret生成session key，接着开始加密传输数据。Keyless SSL2014年，CloudFlare推出了Keyless SSL方式，直至现在大规模使用。其核心在于去除本地秘钥依赖。Yesterday we announced Keyless SSL, CloudFlare’s solution that allows sites to use CloudFlare without requiring them to give up custody of their private keys.使用Keyless SSL之后的RSA过程和DH过程如下：作为了解即可。HTTPS带来的问题全站HTTPS简单来说可能需要注意一下的几个点：购买证书：网站使用HTTPS需要申请安全证书，目前来说还是比较繁琐的，而且对小公司来说是有一些成本在。另外，一定要选正规的机构，否则你的网站以后使用主流浏览器，如chrome访问，会被提示大大的警告，告诉用户该证书有问题。页面里所有资源都要改成走https,包括：图片、js、form表单等等，否则浏览器就会报警。确保用到的CDN节点都支持HTTPS，如果是自建IDC, 必须要保证全国甚至世界范围的 idc 和 cdn 节点，都得覆盖到。所有的开发、测试环境都要做https的升级，确保各级环境保持同一套网络协议。网络耗时增加，简单来说需要多几次握手，网络耗时变长，用户从http跳转到https还要一点时间。计算耗时增加，需要更好机器性能，https要多做一次RSA校验。其中HTTPS带来的性能问题，可以通过优化手段来解决，可以查看案例：详解又拍云 CDN 全站 HTTPS 访问优化。调试当使用全站HTTPS之后，本地和测试环境下仍然是可以不使用HTTPS的。但是在某些场景下（本地前端+线上接口）就一定需要本地使用HTTPS。这里要注意的点：苹果和Chrome都在建议站点使用HTTPS，但是没有要求服务端的证书级别。所以在一些不是很必要的场景，本地制作证书用于本地开发调试。目前关于本地环境使用HTTPS也是有很多优秀的解决方案，这里不多做介绍，可以参考：How to get HTTPS working on your local development environment in 5 minutes参考《Web权威指南》https://blog.csdn.net/a198810…https://developer.mozilla.org...https://developers.google.com…https://zhuanlan.zhihu.com/p/...https://blog.cloudflare.com/k...https://razeen.me/post/ssl-ha… ...

前面都是讲电脑上网的情景，今天我们就来认识下使用最多的移动网络上网场景。移动网络的发展历程 你一定知道手机上网有 2G、3G、4G 的说法，究竟这都是什么意思呢？有一个通俗的说法就是：用 2G 看 txt，用 3G 看 jpg，用 4G 看 avi。2G 网络 手机本来是用来打电话的，不是用来上网的，所以原来在 2G 时代，上网使用的不是 IP 网络，而是电话网络，走模拟信号，专业名称为公共交换电话网（PSTN，Public Switched Telephone Network）。 那手机不连网线，也不连电话线，它是怎么上网的呢？ 手机是通过收发无线信号来通信的，专业名称是 Mobile Station，简称 MS，需要嵌入 SIM。手机是客户端，而无线信号的服务端，就是基站子系统（BSS，Base Station SubsystemBSS）。至于什么是基站，你可以回想一下，你在爬山的时候，是不是看到过信号塔？我们平时城市里面的基站比较隐蔽，不容易看到，所以只有在山里才会注意到。正是这个信号塔，通过无线信号，让你的手机可以进行通信。 但是你要知道一点，无论无线通信如何无线，最终还是要连接到有线的网络里。 因而，基站子系统分两部分，一部分对外提供无线通信，叫作基站收发信台（BTS，Base Transceiver Station），另一部分对内连接有线网络，叫作基站控制器（BSC，Base Station Controller）。基站收发信台通过无线收到数据后，转发给基站控制器。 这部分属于无线的部分，统称为无线接入网（RAN，Radio Access Network）。 基站控制器通过有线网络，连接到提供手机业务的运营商的数据中心，这部分称为核心网（CN，Core Network）。核心网还没有真的进入互联网，这部分还是主要提供手机业务，是手机业务的有线部分。 首先接待基站来的数据的是移动业务交换中心（MSC，Mobile Service Switching Center），它是进入核心网的入口，但是它不会让你直接连接到互联网上。 因为在让你的手机真正进入互联网之前，提供手机业务的运营商，需要认证是不是合法的手机接入。别你自己造了一张手机卡，就连接上来。鉴权中心（AUC，Authentication Center）和设备识别寄存器（EIR，Equipment Identity Register）主要是负责安全性的。 另外，需要看你是本地的号，还是外地的号，这个牵扯到计费的问题，异地收费还是很贵的。访问位置寄存器（VLR，Visit Location Register）是看你目前在的地方，归属位置寄存器（HLR，Home Location Register）是看你的号码归属地。 当你的手机卡既合法又有钱的时候，才允许你上网，这个时候需要一个网关，连接核心网和真正的互联网。网关移动交换中心（GMSC ，Gateway Mobile Switching Center）就是干这个的，然后是真正的互连网。在 2G 时代，还是电话网络 PSTN。 数据中心里面的这些模块统称为网络子系统（NSS，Network and Switching Subsystem）。因而 2G 时代的上网如图所示，我们总结一下，有这几个核心点：手机通过无线信号连接基站；基站一面朝前接无线，一面朝后接核心网；核心网一面朝前接到基站请求，一是判断你是否合法，二是判断你是不是本地号，还有没有钱，一面通过网关连接电话网络。2.5G 网络 后来从 2G 到了 2.5G，也即在原来电路交换的基础上，加入了分组交换业务，支持 Packet 的转发，从而支持 IP 网络。 在上述网络的基础上，基站一面朝前接无线，一面朝后接核心网。在朝后的组件中，多了一个分组控制单元（PCU，Packet Control Unit），用以提供分组交换通道。 在核心网里面，有个朝前的接待员（SGSN，Service GPRS Supported Node）和朝后连接 IP 网络的网关型 GPRS 支持节点（GGSN，Gateway GPRS Supported Node）。3G 网络 到了 3G 时代，主要是无线通信技术有了改进，大大增加了无线的带宽。 以 W-CDMA 为例，理论最高 2M 的下行速度，因而基站改变了，一面朝外的是 Node B，一面朝内连接核心网的是无线网络控制器（RNC，Radio Network Controller）。核心网以及连接的 IP 网络没有什么变化。4G 网络 然后就到了今天的 4G 网络，基站为 eNodeB，包含了原来 Node B 和 RNC 的功能，下行速度向百兆级别迈进。另外，核心网实现了控制面和数据面的分离，这个怎么理解呢？ 在前面的核心网里面，有接待员 MSC 或者 SGSN，你会发现检查是否合法是它负责，转发数据也是它负责，也即控制面和数据面是合二为一的，这样灵活性比较差，因为控制面主要是指令，多是小包，往往需要高的及时性；数据面主要是流量，多是大包，往往需要吞吐量。 于是有了下面这个架构： HSS 用于存储用户签约信息的数据库，其实就是你这个号码归属地是哪里的，以及一些认证信息。 MME 是核心控制网元，是控制面的核心，当手机通过 eNodeB 连上的时候，MME 会根据 HSS 的信息，判断你是否合法。如果允许连上来，MME 不负责具体的数据的流量，而是 MME 会选择数据面的 SGW 和 PGW，然后告诉 eNodeB，我允许你连上来了，你连接它们吧。 于是手机直接通过 eNodeB 连接 SGW，连上核心网，SGW 相当于数据面的接待员，并通过 PGW 连到 IP 网络。PGW 就是出口网关。在出口网关，有一个组件 PCRF，称为策略和计费控制单元，用来控制上网策略和流量的计费。4G 网络协议解析 我们来仔细看一下 4G 网络的协议，真的非常复杂。我们将几个关键组件放大来看。控制面协议 其中虚线部分是控制面的协议。当一个手机想上网的时候，先要连接 eNodeB，并通过 S1-MME 接口，请求 MME 对这个手机进行认证和鉴权。S1-MME 协议栈如下图所示。 UE 就是你的手机，eNodeB 还是两面派，朝前对接无线网络，朝后对接核心网络，在控制面对接的是 MME。 eNodeB 和 MME 之间的连接就是很正常的 IP 网络，但是这里面在 IP 层之上，却既不是 TCP，也不是 UDP，而是 SCTP。这也是传输层的协议，也是面向连接的，但是更加适合移动网络。 它继承了 TCP 较为完善的拥塞控制并改进 TCP 的一些不足之处。 SCTP 的第一个特点是多宿主。一台机器可以有多个网卡，而对于 TCP 连接来讲，虽然服务端可以监听 0.0.0.0，也就是从哪个网卡来的连接都能接受，但是一旦建立了连接，就建立了四元组，也就选定了某个网卡。 SCTP 引入了联合（association）的概念，将多个接口、多条路径放到一个联合中来。当检测到一条路径失效时，协议就会通过另外一条路径来发送通信数据。应用程序甚至都不必知道发生了故障、恢复，从而提供更高的可用性和可靠性。 SCTP 的第二个特点是将一个联合分成多个流。一个联合中的所有流都是独立的，但均与该联合相关。每个流都给定了一个流编号，它被编码到 SCTP 报文中，通过联合在网络上传送。在 TCP 的机制中，由于强制顺序，导致前一个不到达，后一个就得等待，SCTP 的多个流不会相互阻塞。 SCTP 的第三个特点是四次握手，防止 SYN 攻击。在 TCP 中是三次握手，当服务端收到客户的 SYN 之后，返回一个 SYN-ACK 之前，就建立数据结构，并记录下状态，等待客户端发送 ACK 的 ACK。当恶意客户端使用虚假的源地址来伪造大量 SYN 报文时，服务端需要分配大量的资源，最终耗尽资源，无法处理新的请求。 SCTP 可以通过四次握手引入 Cookie 的概念，来有效地防止这种攻击的产生。在 SCTP 中，客户机使用一个 INIT 报文发起一个连接。服务器使用一个 INIT-ACK 报文进行响应，其中就包括了 Cookie。然后客户端就使用一个 COOKIE-ECHO 报文进行响应，其中包含了服务器所发送的 Cookie。这个时候，服务器为这个连接分配资源，并通过向客户机发送一个 COOKIE-ACK 报文对其进行响应。 SCTP 的第四个特点是将消息分帧。TCP 是面向流的，也即发送的数据没头没尾，没有明显的界限。这对于发送数据没有问题，但是对于发送一个个消息类型的数据，就不太方便。有可能客户端写入 10 个字节，然后再写入 20 个字节。服务端不是读出 10 个字节的一个消息，再读出 20 个字节的一个消息，而有可能读入 25 个字节，再读入 5 个字节，需要业务层去组合成消息。 SCTP 借鉴了 UDP 的机制，在数据传输中提供了消息分帧功能。当一端对一个套接字执行写操作时，可确保对等端读出的数据大小与此相同。 SCTP 的第五个特点是断开连接是三次挥手。在 TCP 里面，断开连接是四次挥手，允许另一端处于半关闭的状态。SCTP 选择放弃这种状态，当一端关闭自己的套接字时，对等的两端全部需要关闭，将来任何一端都不允许再进行数据的移动了。 当 MME 通过认证鉴权，同意这个手机上网的时候，需要建立一个数据面的数据通路。建立通路的过程还是控制面的事情，因而使用的是控制面的协议 GTP-C。 建设的数据通路分两段路，其实是两个隧道。一段是从 eNodeB 到 SGW，这个数据通路由 MME 通过 S1-MME 协议告诉 eNodeB，它是隧道的一端，通过 S11 告诉 SGW，它是隧道的另一端。第二端是从 SGW 到 PGW，SGW 通过 S11 协议知道自己是其中一端，并主动通过 S5 协议，告诉 PGW 它是隧道的另一端。 GTP-C 协议是基于 UDP 的，这是UDP 的 “城会玩” 中的一个例子。如果看 GTP 头，我们可以看到，这里面有隧道的 ID，还有序列号。 通过序列号，不用 TCP，GTP-C 自己就可以实现可靠性，为每个输出信令消息分配一个依次递增的序列号，以确保信令消息的按序传递，并便于检测重复包。对于每个输出信令消息启动定时器，在定时器超时前未接收到响应消息则进行重发。数据面协议 当两个隧道都打通，接在一起的时候，PGW 会给手机分配一个 IP 地址，这个 IP 地址是隧道内部的 IP 地址，可以类比为 IPsec 协议里面的 IP 地址。这个 IP 地址是归手机运营商管理的。然后，手机可以使用这个 IP 地址，连接 eNodeB，从 eNodeB 经过 S1-U 协议，通过第一段隧道到达 SGW，再从 SGW 经过 S8 协议，通过第二段隧道到达 PGW，然后通过 PGW 连接到互联网。 数据面的协议都是通过 GTP-U，如图所示： 手机每发出的一个包，都由 GTP-U 隧道协议封装起来，格式如下： 和 IPsec 协议很类似，分为乘客协议、隧道协议、承载协议。其中乘客协议是手机发出来的包，IP 是手机的 IP，隧道协议里面有隧道 ID，不同的手机上线会建立不同的隧道，因而需要隧道 ID 来标识。承载协议的 IP 地址是 SGW 和 PGW 的 IP 地址。手机上网流程 接下来，我们来看一个手机开机之后上网的流程，这个过程称为Attach。可以看出来，移动网络还是很复杂的。因为这个过程要建立很多的隧道，分配很多的隧道 ID，所以我画了一个图来详细说明这个过程。手机开机以后，在附近寻找基站 eNodeB，找到后给 eNodeB 发送 Attach Request，说“我来啦，我要上网”。eNodeB 将请求发给 MME，说“有个手机要上网”。MME 去请求手机，一是认证，二是鉴权，还会请求 HSS 看看有没有钱，看看是在哪里上网。当 MME 通过了手机的认证之后，开始分配隧道，先告诉 SGW，说要创建一个会话（Create Session）。在这里面，会给 SGW 分配一个隧道 ID t1，并且请求 SGW 给自己也分配一个隧道 ID。SGW 转头向 PGW 请求建立一个会话，为 PGW 的控制面分配一个隧道 ID t2，也给 PGW 的数据面分配一个隧道 ID t3，并且请求 PGW 给自己的控制面和数据面分配隧道 ID。PGW 回复 SGW 说“创建会话成功”，使用自己的控制面隧道 ID t2，回复里面携带着给 SGW 控制面分配的隧道 ID t4 和控制面的隧道 ID t5，至此 SGW 和 PGW 直接的隧道建设完成。双方请求对方，都要带着对方给自己分配的隧道 ID，从而标志是这个手机的请求。接下来 SGW 回复 MME 说“创建会话成功”，使用自己的隧道 ID t1 访问 MME，回复里面有给 MME 分配隧道 ID t6，也有 SGW 给 eNodeB 分配的隧道 ID t7。当 MME 发现后面的隧道都建设成功之后，就告诉 eNodeB，“后面的隧道已经建设完毕，SGW 给你分配的隧道 ID 是 t7，你可以开始连上来了，但是你也要给 SGW 分配一个隧道 ID”。eNodeB 告诉 MME 自己给 SGW 分配一个隧道，ID 为 t8。MME 将 eNodeB 给 SGW 分配的隧道 ID t8 告知 SGW，从而前面的隧道也建设完毕。 这样，手机就可以通过建立的隧道成功上网了。异地上网问题 接下来我们考虑异地上网的事情。 为什么要分 SGW 和 PGW 呢，一个 GW 不可以吗？SGW 是你本地的运营商的设备，而 PGW 是你所属的运营商的设备。 如果你在巴塞罗那，一下飞机，手机开机，周围搜寻到的肯定是巴塞罗那的 eNodeB。通过 MME 去查寻国内运营商的 HSS，看你是否合法，是否还有钱。如果允许上网，你的手机和巴塞罗那的 SGW 会建立一个隧道，然后巴塞罗那的 SGW 和国内运营商的 PGW 建立一个隧道，然后通过国内运营商的 PGW 上网。 这样判断你是否能上网的在国内运营商的 HSS，控制你上网策略的是国内运营商的 PCRF，给手机分配的 IP 地址也是国内运营商的 PGW 负责的，给手机分配的 IP 地址也是国内运营商里统计的。运营商由于是在 PGW 里面统计的，这样你的上网流量全部通过国内运营商即可，只不过巴塞罗那运营商也要和国内运营商进行流量结算。 由于你的上网策略是由国内运营商在 PCRF 中控制的，因而你还是上不了脸书。小结移动网络的发展历程从 2G 到 3G，再到 4G，逐渐从打电话的功能为主，向上网的功能为主转变；请记住 4G 网络的结构，有 eNodeB、MME、SGW、PGW 等，分控制面协议和数据面协议，你可以对照着结构，试着说出手机上网的流程；即便你在国外的运营商下上网，也是要通过国内运营商控制的，因而也上不了脸书。 ...

大学时，学到网络协议的7层模型时，老师教了大家一个顺口溜：物数网传会表应。并说这是重点，年年必考，5分的题目摆在这里，你们爱背不背。考试的时候，果然遇到这个问题，搜索枯肠，只能想到这7个字的第一个字，因为这5分，差点挂科。后来工作面试，面试官也是很喜欢七层模型，三次握手之类的问题，但是遇到这些问题时，总是觉得很心虚。1. 协议分层四层网络协议模型中，应用层以下一般都是交给操作系统来处理。应用层对于四层模型来说，仅仅是冰山一角。海面下巨复杂的三层协议，都被操作系统给隐藏起来了，一般我们在页面上发起一个ajax请求，看见了network面板多了一个http请求，至于底层是如何实现的，我们并不关心。应⽤层负责处理特定的应⽤程序细节。运输层运输层主要为两台主机上的应⽤程序提供端到端的通信。网络层处理理分组在⽹网络中的活动，例例如分组的选路链路层处理理与电缆(或其他任何传输媒介)的物理理接⼝口细节下面重点讲一下运输层和网络层1.1. 运输层的两兄弟运输层有两个比较重要的协议。tcp和udp。大哥tcp是比较严谨认真、温柔体贴、慢热内向的协议，发出去的消息，总是一个一个认真检查，等待对方回复和确认，如果一段时间内，对方没有回复确认消息，还会再次发送消息，如果对方回复说你发的太快了，tcp还会体贴的把发送消息的速度降低。弟弟udp则比较可爱呆萌、调皮好动、不负责任的协议。哥哥tcp所具有的特点，弟弟udp一个也没有。但是有的人说不清哪里好 但就是谁都替代不了，udp没有tcp那些复杂的校验和重传等复杂的步骤，所以它发送消息非常快，而且并不保证对方一定收到。如果对方收不到消息，那么udp就会呆萌的看着你，笑着对你说：我已经尽力了。一般语音而视频数据都是用udp协议传输的，因为音频或者视频卡了一下并不影响整体的质量，而对实时性的要求会更高。1.2. 运输层和网络层的区别运输层关注的是端到端层面，及End1到End2，忽略中间的任何点。网络层关注两点之间的层面，即hop1如何到hop2，hop2如何到hop3网络层并不保证消息可靠性，可靠性上层的传输层负责。TCP采用超时重传，分组确认的机制，保证消息不会丢失。从下图tcp, udp, ip协议中，可以发现传输层的tcp和udp都是有源端口和目的端口，但是没有ip字段源ip和目的ip只在ip数据报中理解各个协议，关键在于理解报文的各个字段的含义1.3. ip和端口号的真正含义上个章节讲到运输层和网络层的区别，其中端口号被封装在运输层，ip被封装到网络成，那么端口号和ip地址到底有什么区别呢？ip用来用来标记主机的位置端口号用来标记该数据应该被目标主机上的哪个应用程序去处理1.4. 数据在协议栈的流动 封装与分用当发送消息时，数据在向下传递时，经过不同层次的协议处理，打上各种头部信息当接受消息时，数据在向上传递，通过不同的头部信息字段，才知道要交给上层的那个模块来处理。比如一个ip包，如果没有头部信息，那么这个消息究竟是交给tcp协议来处理，还是udp来处理，就不得而知了2. 深入阅读，好书推荐《http权威指南》 有人说这本书太厚，偷偷告诉你，其实这本书并厚，因为这本书的后面的30%部分都是附录，这本书的精华是前50%的部分《图解http》、《图解tcp/ip》这两本图解的书，知识点讲的都是比较通俗易懂的，适合入门《tcp/ip 详解 卷1》这本书，让你知其然，更知其所以然《tcp/ip 基础》、《tcp/ip 路由技术》这两本书，会让你从不同角度思考协议《精通wireshark》、《wireshark网络分析实战》如果你看了很多书，却从来没有试过网络抓包，那你只是懂纸上谈兵罢了。你永远无法理解tcp三次握手的怦然心动，与四次分手的刻骨铭心。

第一层（物理层）第二层（数据链路层）第一，MAC 层是用来解决多路访问的堵车问题的；第二，ARP 是通过吼的方式来寻找目标 MAC 地址的，吼完之后记住一段时间，这个叫作缓存；第三，交换机是有 MAC 地址学习能力的，学完了它就知道谁在哪儿了，不用广播了。

如何配置 IP 地址？那如何配置呢？如果有相关的知识和积累，你可以用命令行自己配置一个地址。可以使用 ifconfig，也可以使用 ip addr。设置好了以后，用这两个命令，将网卡 up 一下，就可以开始工作了。使用 net-tools：$ sudo ifconfig eth1 10.0.0.1/24 $ sudo ifconfig eth1 up 使用 iproute2：$ sudo ip addr add 10.0.0.1/24 dev eth1$ sudo ip link set up eth1你可能会问了，自己配置这个自由度太大了吧，我是不是配置什么都可以？如果配置一个和谁都不搭边的地址呢？例如，旁边的机器都是 192.168.1.x，我非得配置一个 16.158.23.6，会出现什么现象呢？不会出现任何现象，就是包发不出去呗。为什么发不出去呢？我来举例说明。192.168.1.6 就在你这台机器的旁边，甚至是在同一个交换机上，而你把机器的地址设为了16.158.23.6。在这台机器上，你企图去 ping192.168.1.6，你觉得只要将包发出去，同一个交换机的另一台机器马上就能收到，对不对？可是 Linux 系统不是这样的，它没你想得那么智能。你用肉眼看到那台机器就在旁边，它则需要根据自己的逻辑进行处理。还记得我们在第二节说过的原则吗？只要是在网络上跑的包，都是完整的，可以有下层没上层，绝对不可能有上层没下层。所以，你看着它有自己的源 IP 地址 16.158.23.6，也有目标 IP 地址 192.168.1.6，但是包发不出去，这是因为 MAC 层还没填。自己的 MAC 地址自己知道，这个容易。但是目标 MAC 填什么呢？是不是填 192.168.1.6 这台机器的MAC 地址呢？当然不是。Linux 首先会判断，要去的这个地址和我是一个网段的吗，或者和我的一个网卡是同一网段的吗？只有是一个网段的，它才会发送 ARP 请求，获取 MAC 地址。如果发现不是呢？Linux 默认的逻辑是，如果这是一个跨网段的调用，它便不会直接将包发送到网络上，而是企图将包发送到网关。如果你配置了网关的话，Linux 会获取网关的 MAC 地址，然后将包发出去。对于 192.168.1.6 这台机器来讲，虽然路过它家门的这个包，目标 IP 是它，但是无奈 MAC 地址不是它的，所以它的网卡是不会把包收进去的。如果没有配置网关呢？那包压根就发不出去。如果将网关配置为 192.168.1.6 呢？不可能，Linux 不会让你配置成功的，因为网关要和当前的网络至少一个网卡是同一个网段的，怎么可能 16.158.23.6 的网关是 192.168.1.6 呢？所以，当你需要手动配置一台机器的网络 IP 时，一定要好好问问你的网络管理员。如果在机房里面，要去网络管理员那里申请，让他给你分配一段正确的 IP 地址。当然，真正配置的时候，一定不是直接用命令配置的，而是放在一个配置文件里面。不同系统的配置文件格式不同，但是无非就是 CIDR、子网掩码、广播地址和网关地址。动态主机配置协议（DHCP）原来配置 IP 有这么多门道儿啊。你可能会问了，配置了 IP 之后一般不能变的，配置一个服务端的机器还可以，但是如果是客户端的机器呢？我抱着一台笔记本电脑在公司里走来走去，或者白天来晚上走，每次使用都要配置 IP 地址，那可怎么办？还有人事、行政等非技术人员，如果公司所有的电脑都需要 IT人员配置，肯定忙不过来啊。因此，我们需要有一个自动配置的协议，也就是称动态主机配置协议（Dynamic Host ConfigurationProtocol），简称DHCP。有了这个协议，网络管理员就轻松多了。他只需要配置一段共享的 IP 地址。每一台新接入的机器都通过DHCP 协议，来这个共享的 IP 地址里申请，然后自动配置好就可以了。等人走了，或者用完了，还回去，这样其他的机器也能用。所以说，如果是数据中心里面的服务器，IP 一旦配置好，基本不会变，这就相当于买房自己装修。DHCP 的方式就相当于租房。你不用装修，都是帮你配置好的。你暂时用一下，用完退租就可以了。解析 DHCP 的工作方式当一台机器新加入一个网络的时候，肯定一脸懵，啥情况都不知道，只知道自己的 MAC 地址。怎么办？先吼一句，我来啦，有人吗？这时候的沟通基本靠“吼”。这一步，我们称为DHCP Discover。新来的机器使用 IP 地址 0.0.0.0 发送了一个广播包，目的 IP 地址为 255.255.255.255。广播包封装在UDP 里面，UDP 封装在 BOOTP 里面。其实 DHCP 是 BOOTP 的增强版，但是如果你去抓包的话，很可能看到的名称还是 BOOTP 协议。在这个广播包里面，新人大声喊：我是新来的（Boot request），我的 MAC 地址是这个，我还没有IP，谁能给租给我个 IP 地址！DHCP 协议主要是用来给客户租用 IP 地址，和房产中介很像，要商谈、签约、续租，广播还不能“抢单”；DHCP 协议能给客户推荐“装修队”PXE，能够安装操作系统，这个在云计算领域大有用处 ...

怎样查看电脑本机ip地址？答案是在 Windows 上是 ipconfig，在 Linux 上是 ifconfig，Linux上还有一种查看的方法 ip addr。10.100.122.2 就是一个 IP 地址。这个地址被点分隔为四个部分，每个部分 8 个 bit，所以 IP 地址总共是 32 位。这样产生的 IP 地址的数量很快就不够用了。因为当时设计 IP 地址的时候，哪知道今天会有这么多的计算机啊！因为不够用，于是就有了 IPv6，输出结果里面 inet6fe80::f816:3eff:fec7:7975/64。这个有 128 位，现在看来是够了举例：一个容易“犯错”的 CIDR我们来看 16.158.165.91/22 这个 CIDR。求一下这个网络的第一个地址、子网掩码和广播地址。你要是上来就写 16.158.165.1，那就大错特错了。/22 不是 8 的整数倍，不好办，只能先变成二进制来看。16.158 的部分不会动，它占了前 16 位。中间的 165，变为二进制为10100101。除了前面的 16 位，还剩 6 位。所以，这 8 位中前 6 位是网络号，6.158.<101001>，而<01>.91 是机器号。第一个地址是 16.158.<101001><00>.1，即 16.158.164.1。子网掩码是 255.255.<111111><00>.0，即 255.255.252.0。广播地址为 16.158.<101001><11>.255，即 16.158.167.255。IP 是地址，有定位功能；MAC 是身份证，无定位功能；CIDR 可以用来判断是不是本地人；IP 分公有的 IP 和私有的 IP。

为什么网络要分层呀？因为不同的层次之间有不同的沟通方式，这个叫作协议。始终想象自己是一个处理网络包的程序：如何拿到网络包，如何根据规则进行处理，如何发出去；始终牢记一个原则：只要是在网络上跑的包，都是完整的。可以有下层没上层，绝对不可能有上层没下层。

我们常用的网络协议有哪些？ 你先在浏览器里面输入 https://www.kaola.com ，这是一个URL。浏览器只知道名字是“www.kaola.com”，但是不知道具体的地点，所以不知道应该如何访问。于是，它打开地址簿去查找。可以使用一般的地址簿协议DNS去查找，还可以使用另一种更加精准的地址簿查找协议HTTPDNS。无论用哪一种方法查找，最终都会得到这个地址：106.114.138.24。这个是IP地址，是互联网世界的“门牌号”。知道了目标地址，浏览器就开始打包它的请求。对于普通的浏览请求，往往会使用HTTP协议；但是对于购物的请求，往往需要进行加密传输，因而会使用HTTPS协议。无论是什么协议，里面都会写明“你要买什么和买多少”。 DNS、HTTP、HTTPS 所在的层我们称为应用层。经过应用层封装后，浏览器会将应用层的包交给下一层去完成，通过 socket 编程来实现。下一层是传输层。传输层有两种协议，一种是无连接的协议UDP，一种是面向连接的协议TCP。对于支付来讲，往往使用 TCP 协议。所谓的面向连接就是，TCP 会保证这个包能够到达目的地。如果不能到达，就会重新发送，直至到达。TCP 协议里面会有两个端口，一个是浏览器监听的端口，一个是电商的服务器监听的端口。操作系统往往通过端口来判断，它得到的包应该给哪个进程。传输层封装完毕后，浏览器会将包交给操作系统的网络层。网络层的协议是 IP 协议。在 IP 协议里面会有源 IP 地址，即浏览器所在机器的 IP 地址和目标 IP 地址，也即电商网站所在服务器的 IP 地址。操作系统既然知道了目标 IP 地址，就开始想如何根据这个门牌号找到目标机器。操作系统往往会判断，这个目标 IP 地址是本地人，还是外地人。如果是本地人，从门牌号就能看出来，但是显然电商网站不在本地，而在遥远的地方。操作系统知道要离开本地去远方。虽然不知道远方在何处，但是可以这样类比一下：如果去国外要去海关，去外地就要去网关。而操作系统启动的时候，就会被 DHCP 协议配置 IP 地址，以及默认的网关的IP 地址 192.168.1.1。操作系统如何将 IP 地址发给网关呢？在本地通信基本靠吼，于是操作系统大吼一声，谁是 192.168.1.1啊？网关会回答它，我就是，我的本地地址在村东头。这个本地地址就是MAC地址，而大吼的那一声是ARP协议。接下来我们将学习各层次网络协议。

上一节我们了解了基于 XML 的 SOAP 协议，SOAP 的 S 是啥意思来着？是 Simple，但是好像一点儿都不简单啊！传输协议问题 对于 SOAP 来讲，比如我创建一个订单，用 POST，在 XML 里面写明动作是 CreateOrder；删除一个订单，还是用 POST，在 XML 里面写明了动作是 DeleteOrder。其实创建订单完全可以使用 POST 动作，然后在 XML 里面放一个订单的信息就可以了，而删除用 DELETE 动作，然后在 XML 里面放一个订单的 ID 就可以了。 于是上面的那个 SOAP 就变成下面这个简单的模样。POST /purchaseOrder HTTP/1.1Host: www.cnblog.comContent-Type: application/xml; charset=utf-8Content-Length: nnn<?xml version=“1.0”?> <order> <date>2018-07-01</date> <className> 板栗焖鸡 </className> <price>58</price> </order> 而且 XML 的格式也可以改成另外一种简单的文本化的对象表示格式 JSON。 经常写 Web 应用的应该已经发现，这就是 RESTful 格式的 API 的样子。协议约定问题 然而 RESTful 可不仅仅是指 API，而是一种架构风格，全称 Representational State Transfer，表述性状态转移，来自一篇重要的论文《架构风格与基于网络的软件架构设计》（Architectural Styles and the Design of Network-based Software Architectures）。 这篇文章从深层次，更加抽象地论证了一个互联网应用应该有的设计要点，而这些设计要点，成为后来我们能看到的所有高并发应用设计都必须要考虑的问题，再加上 REST API 比较简单直接，所以后来几乎成为互联网应用的标准接口。 因此，和 SOAP 不一样，REST 不是一种严格规定的标准，它其实是一种设计风格。如果按这种风格进行设计，RESTful 接口和 SOAP 接口都能做到，只不过后面的架构是 REST 倡导的，而 SOAP 相对比较关注前面的接口。 而且由于能够通过 WSDL 生成客户端的 Stub，因而 SOAP 常常被用于类似传统的 RPC 方式，也即调用远端和调用本地是一样的。 然而本地调用和远程跨网络调用毕竟不一样，这里的不一样还不仅仅是因为有网络而导致的客户端和服务端的分离，从而带来的网络性能问题。更重要的问题是，客户端和服务端谁来维护状态。所谓的状态就是对某个数据当前处理到什么程度了。 这里举几个例子，例如，我浏览到哪个目录了，我看到第几页了，我要买个东西，需要扣减一下库存，这些都是状态。本地调用其实没有人纠结这个问题，因为数据都在本地，谁处理都一样，而且一边处理了，另一边马上就能看到。 当有了 RPC 之后，我们本来期望对上层透明，就像上一节说的“远在天边，尽在眼前”。于是使用 RPC 的时候，对于状态的问题也没有太多的考虑。 就像 NFS 一样，客户端会告诉服务端，我要进入哪个目录，服务端必须要为某个客户端维护一个状态，就是当前这个客户端浏览到哪个目录了。例如，客户端输入 cd hello，服务端要在某个地方记住，上次浏览到 /root/liuchao 了，因而客户的这次输入，应该给它显示 /root/liuchao/hello 下面的文件列表。而如果有另一个客户端，同样输入 cd hello，服务端也在某个地方记住，上次浏览到 /var/lib，因而要给客户显示的是 /var/lib/hello。 不光 NFS，如果浏览翻页，我们经常要实现函数 next()，在一个列表中取下一页，但是这就需要服务端记住，客户端 A 上次浏览到 20～30 页了，那它调用 next()，应该显示 30～40 页，而客户端 B 上次浏览到 100～110 页了，调用 next() 应该显示 110～120 页。 上面的例子都是在 RPC 场景下，由服务端来维护状态，很多 SOAP 接口设计的时候，也常常按这种模式。这种模式原来没有问题，是因为客户端和服务端之间的比例没有失衡。因为一般不会同时有太多的客户端同时连上来，所以 NFS 还能把每个客户端的状态都记住。 公司内部使用的 ERP 系统，如果使用 SOAP 的方式实现，并且服务端为每个登录的用户维护浏览到报表那一页的状态，由于一个公司内部的人也不会太多，把 ERP 放在一个强大的物理机上，也能记得过来。 但是互联网场景下，客户端和服务端就彻底失衡了。你可以想象“双十一”，多少人同时来购物，作为服务端，它能记得过来吗？当然不可能，只好多个服务端同时提供服务，大家分担一下。但是这就存在一个问题，服务端怎么把自己记住的客户端状态告诉另一个服务端呢？或者说，你让我给你分担工作，你也要把工作的前因后果给我说清楚啊！ 那服务端索性就要想了，既然这么多客户端，那大家就分分工吧。服务端就只记录资源的状态，例如文件的状态，报表的状态，库存的状态，而客户端自己维护自己的状态。比如，你访问到哪个目录了啊，报表的哪一页了啊，等等。 这样对于 API 也有影响，也就是说，当客户端维护了自己的状态，就不能这样调用服务端了。例如客户端说，我想访问当前目录下的 hello 路径。服务端说，我怎么知道你的当前路径。所以客户端要先看看自己当前路径是 /root/liuchao，然后告诉服务端说，我想访问 /root/liuchao/hello 路径。 再比如，客户端说我想访问下一页，服务端说，我怎么知道你当前访问到哪一页了。所以客户端要先看看自己访问到了 100～110 页，然后告诉服务器说，我想访问 110～120 页。 这就是服务端的无状态化。这样服务端就可以横向扩展了，一百个人一起服务，不用交接，每个人都能处理。 所谓的无状态，其实是服务端维护资源的状态，客户端维护会话的状态。对于服务端来讲，只有资源的状态改变了，客户端才调用 POST、PUT、DELETE 方法来找我；如果资源的状态没变，只是客户端的状态变了，就不用告诉我了，对于我来说都是统一的 GET。 虽然这只改进了 GET，但是已经带来了很大的进步。因为对于互联网应用，大多数是读多写少的。而且只要服务端的资源状态不变，就给了我们缓存的可能。例如可以将状态缓存到接入层，甚至缓存到 CDN 的边缘节点，这都是资源状态不变的好处。 按照这种思路，对于 API 的设计，就慢慢变成了以资源为核心，而非以过程为核心。也就是说，客户端只要告诉服务端你想让资源状态最终变成什么样就可以了，而不用告诉我过程，不用告诉我动作。 还是文件目录的例子。客户端应该访问哪个绝对路径，而非一个动作，我就要进入某个路径。再如，库存的调用，应该查看当前的库存数目，然后减去购买的数量，得到结果的库存数。这个时候应该设置为目标库存数（但是当前库存数要匹配），而非告知减去多少库存。 这种 API 的设计需要实现幂等，因为网络不稳定，就会经常出错，因而需要重试，但是一旦重试，就会存在幂等的问题，也就是同一个调用，多次调用的结果应该一样，不能一次支付调用，因为调用三次变成了支付三次。不能进入 cd a，做了三次，就变成了 cd a/a/a。也不能扣减库存，调用了三次，就扣减三次库存。 当然按照这种设计模式，无论 RESTful API 还是 SOAP API 都可以将架构实现成无状态的，面向资源的、幂等的、横向扩展的、可缓存的。 但是 SOAP 的 XML 正文中，是可以放任何动作的。例如 XML 里面可以写 < ADD >，< MINUS > 等。这就方便使用 SOAP 的人，将大量的动作放在 API 里面。 RESTful 没这么复杂，也没给客户提供这么多的可能性，正文里的 JSON 基本描述的就是资源的状态，没办法描述动作，而且能够出发的动作只有 CRUD，也即 POST、GET、PUT、DELETE，也就是对于状态的改变。 所以，从接口角度，就让你死了这条心。当然也有很多技巧的方法，在使用 RESTful API 的情况下，依然提供基于动作的有状态请求，这属于反模式了。服务发现问题 对于 RESTful API 来讲，我们已经解决了传输协议的问题——基于 HTTP，协议约定问题——基于 JSON，最后要解决的是服务发现问题。 有个著名的基于 RESTful API 的跨系统调用框架叫 Spring Cloud。在 Spring Cloud 中有一个组件叫 Eureka。传说，阿基米德在洗澡时发现浮力原理，高兴得来不及穿上裤子，跑到街上大喊：“Eureka（我找到了）！”所以 Eureka 是用来实现注册中心的，负责维护注册的服务列表。 服务分服务提供方，它向 Eureka 做服务注册、续约和下线等操作，注册的主要数据包括服务名、机器 IP、端口号、域名等等。 另外一方是服务消费方，向 Eureka 获取服务提供方的注册信息。为了实现负载均衡和容错，服务提供方可以注册多个。 当消费方要调用服务的时候，会从注册中心读出多个服务来，那怎么调用呢？当然是 RESTful 方式了。 Spring Cloud 提供一个 RestTemplate 工具，用于将请求对象转换为 JSON，并发起 Rest 调用，RestTemplate 的调用也是分 POST、PUT、GET、 DELETE 的，当结果返回的时候，根据返回的 JSON 解析成对象。 通过这样封装，调用起来也很方便。小结SOAP 过于复杂，而且设计是面向动作的，因而往往因为架构问题导致并发量上不去;RESTful 不仅仅是一个 API，而且是一种架构模式，主要面向资源，提供无状态服务，有利于横向扩展应对高并发。 ...

【前五篇】系列文章传送门：网络协议 14 - 流媒体协议：要说爱你不容易网络协议 15 - P2P 协议：小种子大学问网络协议 16 - DNS 协议：网络世界的地址簿网络协议 17 - HTTPDNS：私人定制的 DNS 服务网络协议 18 - CDN：家门口的小卖铺 这几年微服务很火，想必各位博友或多或少的都接触过。微服务概念中，各服务间的相互调用是不可或缺的一环。你知道微服务之间是通过什么方式相互调用的吗？ 你可能说，这还不简单，用 socket 呗。服务之间分调用方和被调用方，我们就建立一个 TCP 或者 UDP 连接进行通信就好了。 说着说着，你可能就会发现，这事儿没那么简单。 我们就拿最简单的场景：客户端调用一个加法函数，将两个整数加起来，返回它们的和。 如果放在本地调用，那是简单的不能再简单，但是一旦变成了远程调用，门槛一下子就上去了。 首先，你要会 socket 编程，至少要先了解咱们这个系列的所有协议 ，然后再看 N 本砖头厚的 socket 程序设计的书，学会咱们了解过的几种 socket 程序设计的模型。 这就使得本来大学毕业就能干的一项工作，变成了一件五年工作经验都不一定干好的工作，而且，搞定了 socket 程序设计，才是万里长征的第一步，后面还有很多问题呢。存在问题问题一：如何规定远程调用的语法？ 客户端如何告诉服务端，我是一个加法，而另一个是减法。是用字符串 “add” 传给你，还是传给你一个整数，比如 1 表示加法，2 表示减法？ 服务端又该如果告诉客户端，我这个是加法，目前只能加整数，不能加小数和字符串。而另一个加法 “add1”，它能实现小数和整数的混合加法，那返回值是什么？正确的时候返回什么，错误的时候又返回什么？问题二：如何传递参数？ 是先传两个整数，后传一个操作数 “add”，还是先传操作符，再传两个整数？ 另外，如果我们是用 UDP 传输，把参数放在一个报文里还好，但如果是 TCP，是一个流，在这个流里面如何区分前后两次调用？问题三：如何表示数据？ 在我们的加法例子中，传递的就是一个固定长度的 int 值，这种情况还好，如果是变长的类型，是一个结构体，甚至是一个类，应该怎么办呢？即使是 int，在不同的平台上长度也不同，该怎么办呢？问题四：如何知道一个服务端都实现了哪些远程调用？从哪个端口可以访问这个远程调用？ 假设服务端实现了多个远程调用，每个实现可能都不在一个进程中，监听的端口也不一样，而且由于服务端都是自己实现的，不可能使用一个大家都公认的端口，而且有可能多个进程部署在一台机器上，大家需要抢占端口，为了防止冲突，往往使用随机端口，那客户端如何找到这些监听的端口呢？问题五：发生了错误、重传、丢包、性能等问题怎么办？ 本地调用没有这个问题，但是一旦到网络上，这些问题都需要处理，因为网络是不可靠的，虽然在同一个连接中，我们还可以通过 TCP 协议保证丢包、重传的问题，但是如果服务器崩溃了又重启，当前连接断开了，TCP 就保证不了了，需要应用自己进行重新调用，重新传输会不会同样的操作做两遍，远程调用性能会不会受影响呢？解决问题 看到这么多问题，是不是很头疼？还记得咱们了解 http 的时候，认识的协议三要素吗？ 本地调用函数里很多问题，比如词法分析、语法分析、语义分析等待，这些问题编译器基本上都帮我们解决了，但是在远程调用中，这些问题我们都要自己考虑。协议约定问题 很多公司对于这个问题，是弄一个核心通信组，里面都是 socket 编程的大牛，实现一个统一的库，让其他业务组的人来调用，业务的人不需要知道中间传输的细节。 通信双方的语法、语义、格式、端口、错误处理等，都需要调用方和被调用方开会商量，双方达成一致。一旦有一方改变，要及时通知对方，否则就会出现问题。 但是，不是每个公司都能通过这种大牛团队解决问题的，而是使用已经实现好的框架。 有一个大牛（Bruce Jay Nelson）通过一篇论文，定义了 RPC 的调用标准。后面所有 RPC 框架都是按照这个标准模式来的。整个过程如下：客户端的应用想发起一个远程调用时，它实际上是通过本地调用方的 Stub。它负责将调用的接口、方法和参数，通过约定的协议规范进行编码，并通过本地 RPCRuntime 进行传输，将调用网络包发送到服务器；服务端的 RPCRuntime 收到请求后，交给提供方 Stub 进行编码，然后调用服务端的方法，获取结果，并将结果编码后，发送给客户端；客户端的 RPCRuntime 收到结果，发给调用方 Stub 解码得到结果，返回给客户端。 上面过程中分了三个层次：客户端、Stub 层、服务端。 对于客户端和服务端，都像是本地调用一样，专注于业务逻辑的处理就可以了。对于 Stub 层，处理双方约定好的语法、语义、封装、解封装。对于 RPCRuntime，主要处理高性能的传输，以及网络的错误和异常。 最早的 RPC 的一种实现方式称为 Sun RPC 或 ONC RPC。Sun 公司是第一个提供商业化 RPC 库和 RPC 编译器的公司。这个 RPC 框架是在 NFS 协议中使用的。 NFS（Network File System）就是网络文件系统。要使 NFS 成功运行，就要启动两个服务端，一个 mountd，用来挂载文件路径。另一个是 nfsd，用来读写文件。NFS 可以在本地 mount 一个远程的目录到本地目录，从而实现让本地用户在本地目录里面读写文件时，操作是是远程另一台机器上的文件。 远程操作和远程调用的思路是一样的，就像本地操作一样，所以 NFS 协议就是基于 RPC 实现的。当然，无论是什么 RPC，底层都是 socket 编程。 XDR（External Data Representation，外部数据表示法）是有一个标准的数据压缩格式，可以表示基本的数据类型，也可以表示结构体。 这里有几种基本的数据类型。 在 RPC 的调用过程中，所有的数据类型都要封装成类似的格式，而且 RPC 的调用和结果返回也有严格的格式。XID 唯一标识请求和回复。请求是 0，回复是 1；RPC 有版本号，两端要匹配 RPC 协议的版本号。如果不匹配，就会返回 Deny，原因是 RPC_MISMATCH；程序有编号。如果服务端找不到这个程序，就会返回 PROG_UNAVAIL；程序有版本号。如果程序的版本号不匹配，就会返回 PROG_MISMATCH；一个程序可以有多个方法，方法也有编号，如果找不到方法，就会返回 PROG_UNAVAIL；调用需要认证鉴权，如果不通过，返回 Deny；最后是参数列表，如果参数无法解析，返回 GABAGE_ARGS； 为了可以成功调用 RPC，在客户端和服务端实现 RPC 的时候，首先要定义一个双方都认可的程序、版本、方法、参数等。 对于上面的加法而言，双方约定为一个协议定义文件，同理，如果是 NFS、mount 和读写，也会有类似的定义。 有了协议定义文件，ONC RPC 会提供一个工具，根据这个文件生成客户端和服务器端的 Stub 程序。 最下层的是 XDR 文件，用于编码和解码参数。这个文件是客户端和服务端共享的，因为只有双方一致才能成功通信。 在客户端，会调用 clnt_create 创建一个连接，然后调用 add_1，这是一个 Stub 函数，感觉是在调用本地函数一样。其实是这个函数发起了一个 RPC 调用，通过调用 clnt_call 来调用 ONC RPC 的类库，来真正发送请求。调用的过程较为复杂，后续再进行专门的说明。 当然，服务端也有一个 Stub 程序，监听客户端的请求，当调用到达的时候，判断如果是 add，则调用真正的服务端逻辑，也就是将两个数加起来。 服务端将结果返回服务端的 Stub，Stub 程序发送结果给客户端 Stub，客户端 Stub 收到结果后就返回给客户端的应用程序，从而完成这个调用过。 有了这个 RPC 框架，前面五个问题中的 “如何规定远程调用的语法？”、“如何传递参数？” 以及 “如何表示数据？” 基本解决了，这三个问题我们统称为协议约定问题。传输问题 前三个问题解决了，但是错误、重传、丢包以及性能问题还没有解决，这些问题我们统称为传输问题。这个 Stub 层就无能为力了，而是由 ONC RPC 的类库来实现。 在这个类库中，为了解决传输问题，对于每一个客户端，都会创建一个传输管理层，而每一次 RPC 调用，都会是一个任务，在传输管理层，你可以看到熟悉的队列机制、拥塞窗口机制等。 由于在网络传输的时候，经常需要等待，而同步的方式往往效率比较低，因而也就有 socket 的异步模型。 为了能够异步处理，对于远程调用的处理，往往是通过状态机来实现的。只有当满足某个状态的时候，才进行下一步，如果不满足状态，不是在那里等待，而是将资源留出来，用来处理其他的 RPC 调用。 如上图，从图也可以看出，这个状态转换图还是很复杂的。 首先，进入起始状态，查看 RPC 的传输层队列中有没有空闲的位置，可以处理新的 RPC 任务，如果没有，说明太忙了，直接结束或重试。如果申请成功，就可以分配内存，获取服务端的端口号，然后连接服务器。 连接的过程要有一段时间，因而要等待连接结果，如果连接失败，直接结束或重试。如果连接成功，则开始发送 RPC 请，然后等待获取 RPC 结果。同样的，这个过程也需要时间，如果发送出错，就重新发送，如果连接断开，要重新连接，如果超时，要重新传输。如果获取到结果，就可以解码，正常结束。 这里处理了连接失败、重试、发送失败、超时、重试等场景，因而实现一个 RPC 框架，其实很有难度。服务发现问题 传输问题解决了，我们还遗留了一个 “如何找到 RPC 服务端的那个随机端口”，这个问题我们称为服务发现问题，在 ONC RPC 中，服务发现是通过 portmapper 实现的。 portmapper 会启动在一个众所周知的端口上，RPC 程序由于是用户自己写的，会监听在一个随机端口上，但是 RPC 程序启动的时候，会向 portmapper 注册。 客户端要访问 RPC 服务端这个程序的时候，首先查询 portmapper，获取 RPC 服务端程序的随机端口，然后向这个随机端口建立连接，开始 RPC 调用。从下图中可以看出，mount 命令的 RPC 调用就是这样实现的。小结远程调用看起来用 socket 编程就可以了，其实是很复杂的，要解决协议约定问题、传输问题和服务发现问题；ONC RPC 框架以及 NFS 的实现，给出了解决上述三大问题的示范性实现，也就是公用协议描述文件，并通过这个文件生成 Stub 程序。RPC 的传输一般需要一个状态机，需要另外一个进程专门做服务发现。参考：刘超-趣谈网络协议系列课；如何给老婆解释什么是RPC; ...

【前五篇】系列文章传送门：网络协议 10 - Socket 编程（上）：实践是检验真理的唯一标准网络协议 11 - Socket 编程（下）：眼见为实耳听为虚网络协议 12 - HTTP 协议：常用而不简单网络协议 13 - HTTPS 协议：加密路上无尽头网络协议 14 - 流媒体协议：要说爱你不容易 “兄弟，有种子吗？” “什么种子？小麦种吗？” “……，来，哥今天带你认识下什么是种子”。 大家说起种子，应该都知道是用来下载资源的。那么资源下载都有哪些方式？种子下载又有什么优势呢？下载电影的两种方式 第一种是通过 HTTP 进行下载。这种方式，有过经历的人应该体会到，当下载文件稍大点，下载速度简直能把人急死。 第二种方式就是是通过 FTP（文件传输协议）。FTP 采用两个 TCP 连接来传输一个文件。控制连接。服务器以被动的方式，打开众所周知用于 FTP 的端口 21，客户端则主动发起连接。该连接将命令从客户端传给服务器，并传回服务器的应答。常用的命令有：lsit - 获取文件目录，reter - 取一个文件，store - 存一个文件；数据连接。每当一个文件在客户端与服务器之间传输时，就创建一个数据连接。FTP 的工作模式 在 FTP 的两个 TCP 连接中，每传输一个文件，都要新建立一个数据连接。基于这个数据连接，FTP 又有两种工作模式：主动模式（PORT）和被动模式（PASV），要注意的是，这里的主动和被动都是站在服务器角度来说的。工作模式过程如下：主动模式工作流程客户端随机打开一个大于 1024 的端口 N，向服务器的命令端口 21 发起连接，同时开放 N+1 端口监听，并向服务器发出“port N+1” 命令；由服务器从自己的数据端口 20，主动连接到客户端指定的数据端口 N+1。被动模式工作流程客户端在开启一个 FTP 连接时，打开两个任意的本地端口 N（大于1024）和 N+1。然后用 N 端口连接服务器的 21 端口，提交 PASV 命令；服务器收到命令，开启一个任意的端口 P（大于 1024），返回“227 entering passive mode”消息，消息里有服务器开放的用来进行数据传输的端口号 P。客户端收到消息，取得端口号 P，通过 N+1 端口连接服务器的 P 端口，进行数据传输。 上面说了 HTTP 下载和 FTP 下载，这两种方式都有一个大缺点-难以解决单一服务器的带宽压力。因为它们使用的都是传统 C/S 结构，这种结构会随着客户端的增多，下载速度越来越慢。这在当今互联网世界显然是不合理的，我们期望能实现“下载人数越多，下载速度不变甚至更快”的愿望。 后来，一种创新的，称为 P2P 的方式实现了我们的愿望。P2P P2P 就是 peer-to-peer。这种方式的特点是，资源一开始并不集中存储在某些设备上，而是分散地存储在多台设备上，这些设备我们称为 peer。 在下载一个文件时，只要得到那些已经存在了文件的 peer 地址，并和这些 peer 建立点对点的连接，就可以就近下载文件，而不需要到中心服务器上。一旦下载了文件，你的设备也就称为这个网络的一个 peer，你旁边的那些机器也可能会选择从你这里下载文件。 通过这种方式解决上面 C/S 结构单一服务器带宽压力问题。如果使用过 P2P2 软件，例如 BitTorrent，你就会看到自己网络不仅有下载流量，还有上传流量，也就是说你加入了这个 P2P 网络，自己可以从这个网络里下载，同时别人也可以从你这里下载。这样就实现了，下载人数越多，下载速度越快的愿望。种子文件（.torent） 上面整个过程是不是很完美？是的，结果很美好，但为了实现这个美好，我们还是有很多准备工作要做的。比如，我们怎么知道哪些 peer 有某个文件呢？ 这就用到我们常说的种子（.torrent）。 .torrent 文件由Announce（Tracker URL）和文件信息两部分组成。 其中，文件信息里有以下内容：Info 区：指定该种子包含的文件数量、文件大小及目录结构，包括目录名和文件名；Name 字段：指定顶层目录名字；每个段的大小：BitTorrent（BT）协议把一个文件分成很多个小段，然后分段下载；段哈希值：将整个种子种，每个段的 SHA-1 哈希值拼在一起。 下载时，BT 客户端首先解析 .torrent 文件，得到 Tracker 地址，然后连接 Tracker 服务器。Tracker 服务器回应下载者的请求，将其他下载者（包括发布者）的 IP 提供给下载者。 下载者再连接其他下载者，根据 .torrent 文件，两者分别对方自己已经有的块，然后交换对方没有的数据。 可以看到，下载的过程不需要其他服务器参与，并分散了单个线路上的数据流量，减轻了服务器的压力。 下载者每得到一个块，需要算出下载块的 Hash 验证码，并与 .torrent 文件中的进行对比。如果一样，说明块正确，不一样就需要重新下载这个块。这种规定是为了解决下载内容的准确性问题。 从这个过程也可以看出，这种方式特别依赖 Tracker。Tracker 需要收集所有 peer 的信息，并将从信息提供给下载者，使下载者相互连接，传输数据。虽然下载的过程是非中心化的，但是加入这个 P2P 网络时，需要借助 Tracker 中心服务器，这个服务器用来登记有哪些用户在请求哪些资源。 所以，这种工作方式有一个弊端，一旦 Tracker 服务器出现故障或者线路被屏蔽，BT 工具就无法正常工作了。那能不能彻底去中心化呢？答案是可以的。去中心化网络（DHT） DHT（Distributed Hash Table），这个网络中，每个加入 DHT 网络的人，都要负责存储这个网络里的资源信息和其他成员的联系信息，相当于所有人一起构成了一个庞大的分布式存储数据库。 而 Kedemlia 协议 就是一种著名的 DHT 协议。我们来基于这个协议来认识下这个神奇的 DHT 网络。 当一个客户端启动 BitTorrent 准备下载资源时，这个客户端就充当了两个角色：peer 角色：监听一个 TCP 端口，用来上传和下载文件。对外表明我这里有某个文件；DHT Node 角色：监听一个 UDP 端口，通过这个角色，表明这个节点加入了一个 DHT 网络。 在 DHT 网络里面，每一个 DHT Node 都有一个 ID。这个 ID 是一个长字符串。每个 DHT Node 都有责任掌握一些“知识”，也就是文件索引。也就是说，每个节点要知道哪些文件是保存哪些节点上的。注意，这里它只需要有这些“知识”就可以了，而它本身不一定就是保存这个文件的节点。 当然，每个 DHT Node 不会有全局的“知识”，也就是说它不知道所有的文件保存位置，只需要知道一部分。这里的一部分，就是通过哈希算法计算出来的。Node ID 和文件哈希值 每个文件可以计算出一个哈希值，而 DHT Node 的 ID 是和哈希值相同长度的串。 对于文件下载，DHT 算法是这样规定的：如果一个文件计算出一个哈希值，则和这个哈希值一样的那个 DHT Node，就有责任知道从哪里下载这个文件，即便它自己没保存这个文件。 当然不一定总这么巧，都能找到和哈希值一模一样的，有可能文件对应的 DHT Node 下线了，所以 DHT 算法还规定：除了一模一样的那个 DHT Node 应该知道文件的保存位置，ID 和这个哈希值非常接近的 N 个 DHT Node 也应该知道。 以上图为例。文件 1 通过哈希运算，得到匹配 ID 的 DHT Node 为 Node C（当然还会有其他的，为了便于理解，咱们就先关注 Node C），所以，Node C 就有责任知道文件 1 的存放地址，虽然 Node C 本身没有存放文件 1。 同理，文件 2 通过哈希计算，得到匹配 ID 的 DHT Node 为 Node E，但是 Node D 和 E 的值很近，所以 Node D 也知道。当然，文件 2 本身不一定在 Node D 和 E 这里，但是我们假设 E 就有一份。 接下来，一个新节点 Node new 上线了，如果要下载文件 1，它首先要加入 DHT 网络。如何加入呢？ 在这种模式下，种子 .torrent 文件里面就不再是 Tracker 的地址了，而是一个 list 的 Node 地址，所有这些 Node 都是已经在 DHT 网络里面的。当然，随着时间的推移，很有可能有退出的，有下线的，这里我们假设，不会所有的都联系不上，总有一个能联系上。 那么，Node new 只要在种子里面找到一个 DHT Node，就加入了网络。 Node new 不知道怎么联系上 Node C，因为种子里面的 Node 列表里面很可能没有 Node C，但是没关系，它可以问。DHT 网络特别像一个社交网络，Node new 会去它能联系上的 Node 问，你们知道 Node C 的联系方式吗？ 在 DHT 网络中，每个 Node 都保存了一定的联系方式，但是肯定没有所有 Node 的联系方式。节点之间通过相互通信，会交流联系方式，也会删除联系方式。这和人们的沟通方式一样，你有你的朋友圈，他有他的朋友圈，你们互相加微信，就互相认识了，但是过一段时间不联系，就可能会删除朋友关系一样。 在社交网络中，还有个著名的六度理论，就是说社交网络中的任何两个人的直接距离不超过六度，也就是即使你想联系比尔盖茨，最多通过六个人就能够联系上。 所以，Node New 想联系 Node C，就去万能的朋友圈去问，并且求转发，朋友再问朋友，直到找到 C。如果最后找不到 C，但是能找到离 C 很近的节点，也可以通过 C 的相邻节点下载文件 1。 在 Node C上，告诉 Node new，要下载文件 1，可以去 B、D、F，这里我们假设 Node new 选择了 Node B，那么新节点就和 B 进行 peer 连接，开始下载。它一旦开始下载，自己本地也有文件 1 了，于是，Node new 就告诉 C 以及 C 的相邻节点，我也有文件 1 了，可以将我加入文件 1 的拥有者列表了。 你可能会发现，上面的过程中漏掉了 Node new 的文件索引，但是根据哈希算法，一定会有某些文件的哈希值是和 Node new 的 ID 匹配的。在 DHT 网络中，会有节点告诉它，你既然加入了咱们这个网络，也就有责任知道某些文件的下载地址了。 好了，完成分布式下载了。但是我们上面的过程中遗留了两个细节性的问题。1）DHT Node ID 以及文件哈希值是什么？ 其实，我们可以将节点 ID 理解为一个 160bits（20字节）的字符串，文件的哈希也使用这样的字符串。2）所谓 ID 相似，具体到什么程度算相似？ 这里就要说到两个节点距离的定义和计算了。 在 Kademlia 网络中，两个节点的距离采用的是逻辑上的距离，假设节点 A 和 节点 B 的距离为 d，则：d = A XOR B 上面说过，每个节点都有一个哈希 ID，这个 ID 由 20 个字符，160 bits 位组成。这里，我们就用一个 5 bits ID 来举例。 我们假设，节点 A 的 ID 是 01010，节点 B 的 ID 是 01001，则：距离 d = A XOR B = 01010 XOR 00011 = 01001 = 9 所以，我们说节点 A 和节点 B 的逻辑距离为 9。 回到我们上面的问题，哈希值接近，可以理解为距离接近，也即，和这个节点距离近的 N 个节点要知道文件的保存位置。 要注意的是，这个距离不是地理位置，因为在 Kademlia 网络中，位置近不算近，ID 近才算近。我们可以将这个距离理解为社交距离，也就是在朋友圈中的距离，或者社交网络中的距离。这个和你的空间位置没有多少关系，和人的经历关系比较大。DHT 网络节点关系的维护 就像人一样，虽然我们常联系的只有少数，但是朋友圈肯定是远近都有。DHT 网络的朋友圈也一样，远近都有，并且按距离分层。 假设某个节点的 ID 为 01010，如果一个节点的 ID，前面所有位数都与它相同，只有最后 1 位不停，这样的节点只有 1 个，为 01011。与基础节点的异或值为 00001，也就是距离为 1。那么对于 01010 而言，这样的节点归为第一层节点，也就是k-buket 1。 类似的，如果一个节点的 ID，前面所有位数和基础节点都相同，从倒数第 2 位开始不同，这样的节点只有 2 个，即 01000 和 01001，与基础节点的亦或值为 00010 和 00011，也就是距离为 2 和 3。这样的节点归为第二层节点，也就是k-bucket 2。 所以，我们可以总结出以下规律：如果一个节点的 ID，前面所有位数相同，从倒数第 i 位开始不同，这样的节点只有 2^(i-1) 个，与基础节点的距离范围为 [2^(i-1), 2^i]，对于原始节点而言，这样的节点归为k-bucket i。 你会发现，差距越大，陌生人就越多。但是朋友圈不能把所有的都放下，所以每一层都只放 K 个，这个 K 是可以通过参数配置的。DHT 网络中查找好友 假设，Node A 的 ID 为 00110，要找 B（10000），异或距离为 10110，距离范围在 [2^4, 2^5)，这就说明 B 的 ID 和 A 的从第 5 位开始不同，所以 B 可能在 k-bucket 5 中。 然后，A 看看自己的 k-bucket 5 有没有 B，如果有，结束查找。如果没有，就在 k-bucket 5 里随便找一个 C。因为是二进制，C、B 都和 A 的第 5 位不停，那么 C 的 ID 第5 位肯定与 B 相同，即它与 B 的距离小于 2^4，相当于 A、B 之间的距离缩短了一半以上。 接着，再请求 C，在 C 的通讯里里，按同样的查找方式找 B，如果 C 找到了 B，就告诉 A。如果 C 也没有找到 B，就按同样的搜索方法，在自己的通讯里里找到一个离 B 更近一步的 D（D、B 之间距离小于 2^3），把 D 推荐给 A，A 请求 D 进行下一步查找。 你可能已经发现了，Kademlia 这种查询机制，是通过折半查找的方式来收缩范围，对于总的节点数目为 N 的网络，最多只需要 log2(N) 次查询，就能够找到目标。 如下图，A 节点找 B 节点，最坏查找情况： 图中过程如下：A 和 B 的每一位都不一样，所以相差 31，A 找到的朋友 C，不巧正好在中间，和 A 的距离是 16，和 B 的距离是 15；C 去自己朋友圈找，碰巧找到了 D，距离 C 为 8，距离 B 为 7；D 去自己朋友圈找，碰巧找到了 E，距离 D 为 4，距离 B 为 3；E 在自己朋友圈找，找到了 F，距离 E 为 2，距离 B 为 1；F 在距离为 1 的地方找到了 B。节点的沟通 在 Kademlia 算法中，每个节点下面 4 个指令：PING：测试一个节点是否在线。相当于打个电话，看还能打通不；STORE：要钱一个节点存储一份数据；FIND_NODE：根据节点 ID 查找一个节点；FIND_VALUE：根据 KEY 查找一个数据，实则上和 FIND_NODE 非常类似。KEY 就是文件对应的哈希值，找到保存文件的节点。节点的更新 整个 DHT 网络，会通过相互通信，维护自己朋友圈好友的状态。每个 bucket 里的节点，都按最后一次接触时间倒序排列。相当于，朋友圈里最近联系的人往往是最熟的；每次执行四个指令中的任意一个都会触发更新；当一个节点与自己接触时，检查它是否已经在 k-bucket 中。就是说是否已经在朋友圈。如果在，那么就将它移到 k-bucket 列表的最底，也就是最新的位置（刚联系过，就置顶下，方便以后多联系）。如果不在，就要考虑新的联系人要不要加到通讯录里面。假设通讯录已满，就 PING 一下列表最上面的节点（最旧的），如果 PING 通了，将旧节点移动到列表最底，并丢弃新节点（老朋友还是要留点情面的）。如 PING 不同，就删除旧节点，并将新节点加入列表（联系不上的老朋友还是删掉吧）。 通过上面这个机制，保证了任意节点的加入和离开都不影响整体网络。小结下载一个文件可以通过 HTTP 或 FTP。这两种都是集中下载的方式，而 P2P 则换了一种思路，采用非中心化下载的方式；P2P 有两种。一种是依赖于 Tracker 的，也就是元数据集中，文件数据分散。另一种是基于分布式的哈希算法，元数据和文件数据全部分散。参考：维基百科-DHT 网络词条；维基百科-Kademlia 词条；刘超 - 趣谈网络协议系列课； ...

【前五篇】系列文章传送门：网络协议 9 - TCP协议（下）：聪明反被聪明误网络协议 10 - Socket 编程（上）：实践是检验真理的唯一标准网络协议 11 - Socket 编程（下）：眼见为实耳听为虚网络协议 12 - HTTP 协议：常用而不简单网络协议 13 - HTTPS 协议：加密路上无尽头 大家都会关注“在浏览器输入一个地址，然后回车，会发生什么”这样一个问题，但是有没有想过这样一个问题：主播开始直播，用户打开客户端观看，这个过程发生了什么？ 随着技术的发展，直播技术对人们生活的渗透日益加深。从最开始的游戏直播，到前几天爆出来的教育直播，甚至现在都有直播招聘。 而我们喜欢的这些直播，他们用到的传输协议有一个通用名-流媒体传输协议。 要认识流媒体协议，就离不开下面的三大系列名词。三大系列名词系列一：AVI、MPEG、RMVB、MP4、MOV、FLV、WebM、WMV、ASF、MKV。是不是就 MP4 看着熟悉？系列二：H.261、H.262、H.263、H.264、H.265。能认出来几个？别着急，重点关注 H.264。系列三：MPEG-1、MPEG-2、MPEG-4、MPEG-7。是不是更懵逼了？ 在解释上面的三大系列名词之前，咱们先来了解下，视频究竟是什么？ 博主记得小时候，经常会玩一种叫动感画册的东西。一本很小的画册上，每一页都画了一幅图，用手快速的翻过每一页，就能看到一个很短的“动画片”。 没错，咱们看到的视频，本质上就是一连串快速播放的图片。 每一张图片，我们称为一帧。只要每秒钟的数据足够多，也就是播放速度足够快，人眼就看不出是一张张独立的图片。对于人眼而言，这个播放临界速度是每秒 30 帧，而这里的 30 也就是我们常说的帧率（FPS)。 每一张图片，都是由像素组成，而每个像素又是由 RGB 组成，每个 8 位，共 24 位。 我们假设一个视频中的所有图片的像素都是 1024*768，可以大概估算下视频的大小：每秒钟大小 = 30 帧 x 1024 x 768 x 24 = 566,231,010 Bits = 70,778,880 Bytes 按我们上面的估算，一分钟的视频大小就是 4,,246,732,800 Bytes，这里已经有 4 个 G 了。 是不是和我们日常接触到的视频大小明显不符？这是因为我们在传输的过程中，将视频压缩了。 为什么要压缩视频？按我们上面的估算，一个一小时的视频，就有 240G，这个数据量根本没办法存储和传输。因此，人们利用编码技术，给视频“瘦身”，用尽量少的 Bit 数保持视频，同时要保证播放的时候，画面仍然很清晰。实际上，编码就是压缩的过程。视频和图片的压缩特点我们之所以能够对视频流中的图片进行压缩，因为视频和图片有下列这些特点：空间冗余：图像的相邻像素之间有较强的相关性，一张图片相邻像素往往是渐变的，而不是突变的，没必要每个像素都完整的保存，可以隔几个保存一个，中间的用算法计算出来。时间冗余：视频序列的相邻图像之间内容相似。一个视频中连续出现的图片也不是突变的，可以根据已有的图片进行预测和推断。视觉冗余：人的视觉系统对某些细节不敏感，因此不会注意到每一个细节，可以允许丢失一些数据。编码冗余：不同像素值出现的概率不同，概率高的用的字节少，概率低的用的字节多，类似霍夫曼编码的思路。 从上面这些特点中可以看出，用于编码的算法非常复杂，而且多种多样。虽然算法多种，但编码过程实际上是类似的，如下图：视频编码的两大流派 视频编码的算法这么多，能不能形成一定的标准呢？当然能，这里咱们就来认识下视频编码的两大流派。流派一：ITU（International tELECOMMUNICATIONS Union）的 VCEG（Video Coding Experts Group），这个称为国际电联下的 VCEG。既然是电信，可想而知，他们最初是做视频编码，主要侧重传输。我们上面的系列名词二，就是这个组织制定的标准。流派二：ISO（International Standards Organization）的 MPEG（Moving Picture Experts Group），这个是 ISO 旗下的 MPEG。本来是做视频存储的，就像咱们场面常说的 VCD 和 DVD。后来也慢慢侧重视频传输了。系列名词三就是这个组织制定的标准。后来，ITU-T（国际电信联盟电信标准化部门）与 MPEG 联合制定了 H.264/MPEG-4 AVC，这也是我们重点关注的。直播数据传输 视频经过编码之后，生动活泼的一帧帧图像就变成了一串串让人看不懂的二进制。这个二进制可以放在一个文件里，然后按照一定的格式保存起来，这里的保存格式，就是系列名词一。 编码后的二进制文件就可以通过某种网络协议进行封装，放在互联网上传输，这个时候就可以进行网络直播了。 网络协议将编码好的视频流，从主播端推送到服务器，在服务器上有个运行了同样协议的服务端来接收这些网络数据包，从而得到里面的视频流，这个过程称为接流。 服务端接到视频流之后，可以滴视频流进行一定的处理，比如转码，也就是从一个编码格式转成另一种格式，这样才能适应各个观众使用的客户端，保证他们都能看到直播。 流处理完毕后，就可以等待观众的客户端来请求这些视频流。观众的客户端请求视频流的过程称为拉流。 如果有非常多的观众同时看一个视频直播，都从一个服务器上拉流，压力就非常大，因此需要一个视频的分发网络，将视频预先加载到就近的边缘节点，这样大部分观众就能通过边缘节点拉取视频，降低服务器的压力。 当观众将视频流拉下来后，就需要进行解码，也就是通过上述过程的逆过程，将一串串看不懂的二进制转变成一帧帧生动的图片，在客户端播放出来。 整个直播过程，可以用下图来描述： 接下来，我们依次来看一下每个过程：编码：将丰富多彩的图片变成二进制流 虽然我们说视频是一张张图片的序列，但如果每张图片都完整，就太大了，因而会将视频序列分成三种帧：I帧，也称关键帧。里面是完整的图片，只需要本帧数据，就可以完成解码。P帧，前向预测编码帧。P 帧表示的是这一帧跟之前一个关键帧（或 P 帧）的差别，解码时需要用之前缓存的画面，叠加上和本帧定义的差别，生成最终画面。B帧，双向预测内插编码帧。B 帧记录的是本帧与前后帧的差别。要解码 B 帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的数据与本帧数据的叠加，取得最终的画面。 可以看出，I 帧最完整，B 帧压缩率最高，而压缩后帧的序列，应该是 IBBP 间隔出现。这就是通过时序进行编码。 在一帧中，分成多个片，每个片中分成多个宏块，每个宏块分成多个子块，这样将一张大图分解成一个个小块，可以方便进行空间上的编码。如下图： 尽管时空非常立体的组成了一个序列，但总归还是要压缩成一个二进制流。这个流是有结构的，是一个个的网络提取层单元（NALU，Network Abstraction Layer Unit）。变成这种格式就是为了传输，因为网络上的传输，默认的是一个个的包，因而这里也就分成了一个个的单元。 如上图，每个 NALU 首先是一个起始标识符，用于标识 NALU 之间的间隔。然后是 NALU 的头，里面主要配置了 NALU 的类型。最后的 Payload 里面是 NALU 承载的数据。 在 NALU 头里面，主要的内容是类型 NAL Type，其中：0x07 表示 SPS，是序列参数集，包括一个图像序列的所有信息，如图像尺寸、视频格式等。0x08 表示 PPS，是图像参数集，包括一个图像的所有分片的所有相关信息，包括图像类型、序列号等。 在传输视频流之前，剥削要传输者两类参数，不然就无法解码。为了保证容错性，每一个 I 帧之前，都会传一遍这两个参数集合。 如果 NALU Header 里面的表示类型是 SPS 或 PPS，则 Payload 中就是真正的参数集的内容。 如果类型是帧，则 Payload 中是真正的视频数据。当然也是一帧帧保存的。前面说了，一帧的内容还是挺多的，因而每一个 NALU 里面保存的是一片。对于每一片，到底是 I 帧，还是 P 帧，亦或是 B 帧，在片结构里面也有 Header，这里面有个类型用来标识帧的类型，然后是片的内容。 这样，整个格式就出来了。一个视频，可以拆分成一系列的帧，每一帧拆分成一系列的片，每一片都放在一个 NALU 里面，NALU 之间都是通过特殊的起始标识符分隔，在每一个 I 帧的第一片前面，要插入单独保存 SPS 和 PPS 的 NALU，最终形成一个长长的 NALU 序列。推流：将数据流打包传输到对端 形成 NALU 序列后，还需要将这个二进制的流打包成网络包进行发送。这里我们以 RTMP 协议为例，进入第二个过程，推流。 RTMP 是基于 TCP 的，因而也需要双方建立一个 TCP 连接。在有 TCP 的连接的基础上，还需要建立一个 RTMP 连接，也就是在程序里面，我们调用 RTMP 类库的 Connet 函数，显式创建一个连接。 RTMP 为什么需要建立一个单独的连接呢？ 因为通信双方需要商量一些事情，保证后续的传输能正常进行。其实主要就是两个事情：确定版本号。如果客户端、服务端的版本号不一致，就不能正常工作；确定时间戳。视频播放中，时间是很重要的一个元素，后面的数据流互通的时候，经常要带上时间戳的差值，因而一开始双方就要知道对方的时间戳。 沟通这些事情，需要发送 6 条消息：客户端发送 C0、C1、C2服务端发送 S0、S1、S2 首先，客户端发送 C0 表示自己的版本号，不必等对方回复，然后发送 C1 表示自己的时间戳。 服务器只有在收到 C0 的时候，才会返回 S0，表明自己的版本号，如果版本不匹配，可以断开连接。 服务器发送完 S0 后，也不用等待，就直接发送自己的时间戳 S1。 客户端收到 S1 时，发一个知道了最烦时间戳的 ACK C2。同理，服务器收到 C1 的时候，发一个知道了对方时间戳的 ACK S2。 于是，握手完成。 握手之后，双方需要互相传递一些控制信息，例如 Chunk 块的大小、窗口大小等。 真正传输数据的时候，还是需要创建一个流 Stream，然后通过这个 Stream 来推流。 推流的过程，就是讲 NALU 放在 Message 里面发送，这个也称为 RTMP Packet 包。其中，Message 的格式就像下图所示： 发送的时候，去掉 NALU 的起始标识符。因为这部分对于 RTMP 协议来讲没有用。接下来，将 SPS 和 PPS 参数集封装成一个 RTMP 包发送，然后发送一个个片的 NALU。 RTMP 在收发数据的时候并不是以 Message 为单位的，而是把 Message 拆分成 Chunk 发送，而且必须在一个 Chunk 发送完成之后，才能开始发送下一个 Chunk。每个 Chunk 中都带有 Message ID，表示属于哪个 Message，接收端也会按照这个 ID 将 Chunk 组装成 Message。 前面连接的时候，设置 Chunk 块大小就是指这个 Chunk。将大的消息变为小的块再发送，可以在低带宽的情况下，减少网络拥塞。 下面用一个分块的示例，来了解下 RTMP 是如何分块的。 假设一个视频的消息长度是 307，而 Chunk 大小约定为 128，那么消息就会被拆分为 3 个 Chunk。 第一个 Chunk 的 Type = 0，表示 Chunk 头是完整的。头里面 Timestamp 为 1000，总长度 Length 为 307，类型为 9，是个视频，Stream ID 为 12346，正文部分承担 128 个字节的 Data。 第二个 Chunk 也要发送 128 个字节，但是由于 Chunk 头和第一个一样，因此它的 Chunk Type = 3，表示头和第一个 Chunk 一样。 第三个 Chunk 要发送的 Data 的长度为 51 个字节，Chunk Type 还是用的 3。 就这样，数据源源不断的到达流媒体服务器，整个过程就像下图： 这个时候，大量观看直播的观众就可以通过 RTMP 协议从流媒体服务器上拉取。为了减轻服务器压力，我们会使用分发网络。 分发网络分为中心和边缘两层。边缘层服务器部署在全国各地及横跨各大运营商里，和用户距离很近。而中心层是流媒体服务集群，负责内容的转发。 智能负载均衡系统，根据用户的地理位置信息，就近选择边缘服务器，为用户提供推/拉流服务。中心层也负责转码服务。例如，将 RTMP 协议的码流转换成 HLS 码流。拉流：观众的客户端看到直播视频 接下来，我们再来看看观众通过 RTMP 拉流的过程。 先读到的是 H.264 的解码参数，例如 SPS 和 PPS，然后对收到的 NALU 组成一个个帧，进行解码，交给播放器播放，这样客户端就能看到直播视频了。小结视频名词比较多，编码两大流派达成了一致，都是通过时间、空间的各种算法来压缩数据；压缩好的数据，为了传输而组成一系列的 NALU，按照帧和片依次排列；排列好的 NALU，在网络传输的是，要按照 RTMP 包的格式进行包装，RTMP 的包会拆分成 Chunk 进行传输；推送到流媒体集群的视频流经过转码和分发，可以被客户端通过 RTMP 协议拉取，然后组合成 NALU，解码成视频格式进行播放。参考：RTMP 协议规范；刘超 - 趣谈网络协议系列课； ...

系列文章传送门：网络协议 1 - 概述网络协议 2 - IP 是怎么来，又是怎么没的？网络协议 3 - 从物理层到 MAC 层网络协议 4 - 交换机与 VLAN：办公室太复杂，我要回学校网络协议 5 - ICMP 与 ping：投石问路的侦察兵网络协议 6 - 路由协议：敢问路在何方？网络协议 7 - UDP 协议：性善碰到城会玩网络协议 8 - TCP 协议（上）：性恶就要套路深网络协议 9 - TCP协议（下）：聪明反被聪明误网络协议 10 - Socket 编程（上）：实践是检验真理的唯一标准网络协议 11 - Socket 编程（下）：眼见为实耳听为虚网络协议 12 - HTTP 协议：常用而不简单 之前说了 HTTP 协议的各种问题，但是它还是陪伴着互联网、陪伴着我们走过了将近二十年的风风雨雨。现在有很多新的协议尝试去取代它，来解决性能、效率等问题，但它还还能靠着“多年的情分”活的滋润。然而，近些年，因为致命的安全问题，它不得不升级成 HTTPS 了。 就拿我们叫外卖来说，我们点外卖的数据包被黑客截获，然后在服务器回复你之前给你回复一个假消息：“好啊，你该付款了，把银行卡号、密码拿来。”，这时如果你真的把卡号和密码发给他，那你的钱包就真的危险了。 为了解决这些问题，我们给 HTTP 引入了加密，变成了 HTTPS。大家千万不要以为 HTTPS 是个新的协议，它实际上就是：HTTPS = HTTP + SSL 层 这里的 SSL 层的主要工作就是加密。加密方式一般分为两种：对称加密和非对称加密。 这两种加密算法，对称加密要比非对称加密的效率要高很多，性能也好很多，所以交互的场景下多用对称加密。对称加密 在对称加密算法中，加密和解密的密钥是相同的。也就是说，加密和解密使用的是同一个密钥。因此，使用者一定要做好保密功能，不能让第三方知道。 假设叫外卖的你和第三方约定了一个密钥 A，你发送请求的时候用 A 进行加密，外卖网站也用 A 进行解密，这样就算黑客截获了你们的请求，但是没有正确的密钥，还是破解不了。 看起来很好的解决了黑客的问题。但是这里又引入了一个问题，你和外卖网站怎么来约定这个密钥呢？如果这个密钥在互联网上传输，就必须还得用 B 密钥来加密，否则被黑客获取到 A，你们的交互还是不安全，而且，你们又怎么约定 B 呢？所以，只能通过线下传输。 线下传输的话，看过《肖申克的救赎》的博友应该知道，安迪越狱前给瑞德约定了一个地点，让他去那里拿一个信封，里面写着他的住处。 那我们和外卖网站也可以用这样的骚操作，偷偷约定时间地点，它给你一个纸条，上面写着你们两个的密钥，然后就用这个密钥在互联网定外卖。 打住打住，上面这个操作想想都不可思议，如果最初的互联网是这样发展的话，那相信肯定活不久。 相信你也发现了，只有对称加密，就会陷入密钥安全问题的死循环里，这时候，就需要非对称加密了。非对称加密 在非对称加密中 ，加密和解密过程中使用两个不相同的密钥。一个是公开的公钥，另一个是谁都不给的私钥。公钥加密的信息，只有私钥才能解密，而私钥加密的信息，也只有公钥才能解密。 放到外面上面的叫外卖过程中，非对称加密的私钥由外卖网站保存，不会再网上传输，这样就保证了私钥的私密性。与之对应的公钥是可以在互联网上随意传播的，只要外卖网站把这个公钥给你，你们就可以安全的互通了。 还是来看我们点外卖的过程。我们用公钥加密，说“我要豆浆加油条”。黑客在中间截获了这个数据包，但是他没有私钥，没法解密数据，因此可以顺利到达外卖网站。而外卖网站用私钥把这个报文解出来，然后回复，“我知道了，你付款吧，给我卡号和密码”。 整个过程好像很安全，再也不怕黑客了。但是，先别太乐观，你的银行卡是安全了，但是外卖网站可还是有危险的。黑客有外卖网站的公钥，可以模拟发送“我要定外卖”这个信息。 为了解决这个问题，看来一对公钥私钥是不够的，客户端也需要有自己的公钥和私钥，并且客户端也要把自己的公钥给外卖网站。 这样，客户端给外卖网站发送信息的时候，用外卖网站的公钥加密，而外卖网站给客户端发送消息的时候，使用客户端的公钥。这样就算有黑客企图模拟客户端获取一些信息，或者半路截获回复信息，但是由于它没有私钥，这些信息它还是打不开。 说了那么多，相信你也发现了，非对称加密也会有同样的问题，如何将不对称加密的公钥给对方？这时有两种可行方式，一种是放在一个公网的地址上，让对方下载，另一种就是在建立连接的时候传给对方。 这两种方法也有相同的问题。作为普通网民，你怎么鉴别别人给你的公钥是对方的，而不是被黑客冒充的？要知道，每个人都是可以创建自己的公钥和私钥的，创建过程如下：# bash// 创建私钥：openssl genrsa -out httpsprivate.key 1024// 根据私钥获取公钥openssl rsa -in httpsprivate.key -pubout -out httpspublic.pemHTTPS 证书 可以看到，通过工具，我们可以很容易的创建公钥和私钥，那么黑客也是可以创建的，咱们怎么知道外卖网站传过来的公钥是不是真的就是外卖网站的呢？这时候，就需要第三方机构来当这个中间人了。 这就像我们的户口本一样，每个人都可以打印出来，说是真的户口本，但是去使用的时候，人家就只认有公安局盖章的户口本。这个由权威部门颁发的称为**证书（Certificate）。 HTTPS 证书里面应该有以下内容：公钥：这是最重要的；所有者：说明证书是属于谁的，就像户口本上的姓名和身份证号，来证明这个户口本是你的；证书发布机构：看看你的户口本上有没有某某公安局的字样？证书有效时间：这个和咱们身份证有效期是一个意思。 说完了证书的内容，就到了下一步，怎么获取证书？这就像家里添了个小公举，去哪里上户口呢？恐怕大家都知道去公安局。与之对应的，HTTPS 也有专门负责派发证书的机构，这个机构我们称为 CA（Certificate Authrity）。而证书则可以通过下面这个命令生成：openssl req -key httpsprivate.key -new -out httpscertificate.req 将这个请求发给 CA，CA 会给这个证书“盖”一个章，我们称为签名算法。这个签名用到 CA 的私钥进行签发，来保证签名不被伪造。 签名算法大概是这样工作的：一般是对信息做一个 Hash 计算，得到一个 Hash 值，这个过程是不可逆的，也就是说无法通过 Hash 值还原回原来的信息内容。再把信息发出时，把上面得到的 Hash 加密后，作为一个签名和信息一起发出去。CA 给整数签名的命令是：openssl x509 -req -in httpscertificate.req -CA cacertificate-pem -CAkey caprivate.key 这个命令会返回 Signature ok，而 httpscertificate.pem 就是签名过的整数。CA 用自己的私钥给外卖网站的公钥签名，这就相当于给外卖网站背书，形成了外卖网站的证书。我们可以通过下面这个命令查看证书内容：openssl x509 -in httpscertificate.pem -noout -text 证书会显示以下内容：lssuer：证书颁发者；Subject：证书颁发给谁；Validity：证书期限；Public-key：公钥内容；Sinature Algorithm：签名算法 通过这种方式，我们访问外卖网站时，得到的不再是一个公钥，而是一个整数。这个证书里有发布机构 CA，你只要通过这个 CA 的公钥去解密外卖网站证书的签名，解密成功，Hash 对的上，就说明外卖网站的公钥是真实可信的。 上述整个过程中，都有一个前提，CA 是可信的。但是，我们又怎么确定 CA 的公钥就是对的呢？这就像有的人在偏远农村搞了个假公安局一样（应该没人这么干吧），我们怎么知道公安局是不是假的呢？然后我们就会想到，我去县公安局确认下当地公安局的信息不就好了。没错，CA 也是这么干的。 CA 的公钥也需要更牛的 CA 给它签名，然后形成 CA 的公钥。要想知道某个 CA 的证书是否可靠，要看 CA 的上级证书的公钥能不能解开这个 CA 的签名。这样追根溯源，直到全球皆知的几大著名 CA，我们称为Root CA，做最后的背书。正是通过这种层层授信背书的形式，保证了非对称加密模式的争吵运转。 除此之外，还有一种证书， 称为Self-Signed Certificate，就是自己给自己签名。这个就给人一种“我就是我，不一样的烟火，你爱信不信”的感觉，有兴趣的博友可以自行搜索了解。HTTPS 的工作模式 上面说了对称加密和非对称加密的原理，我们知道了非对称加密在性能上远不如对称加密，那在 HTTP 中，能否将两者结合起来呢？例如，公钥私钥主要用于传输对称加密的密钥，而真正的双方大数据量的通信都是通过对称加密进行。 是的，HTTPS 协议的思路就是这样的。如下图： 图比较长，整个过程最后的目标是生成在后续通信过程中使用的对称密钥，以及约定使用的加密算法。整体过程如下：客户端明文发送 TLS 版本信息、加密套件候选列表、压缩算法候选列表等信息，另外还会发送一个随机数，在协商对称密钥的时候使用（你好，我想定外卖，但你要保密我点了什么。这是我的加密套路列表，还有一个随机数 A，你留着）；服务器返回 Server Hello 消息，告诉客户端，服务器选择使用的协议版本、加密套件、压缩算法等，还有一个随机数 B，用于后续进行密钥协商（你好，保密没问题，就按套路 2 来吧，我也给你一个随机数 B，你留着）；服务器给客户端证书；客户端从自己信任的 CA 仓库中，拿 CA 的证书里面的公钥去解密服务器传来的证书。解密成功，说明外卖网站是可信的。这个解密过程，客户端可能胡不断往上追溯 CA、CA 的 CA、CA 的 CA 的 CA，直到一个授信的 CA 为止；证书验证可信后，客户端会计算产生随机数字 Pre-master，发送Client Key Exchange，用证书中的公钥加密，再发给服务器； 到此时，无论是客户端还是服务端，都有了三个随机数，分别是：A、B、Pre-master。通过这三个随机数，客户端和服务端可以产生相同的对称密钥。 约定好对称密钥和加密算法，就可以用对称加密的形式进行加密通信了，后续的通信除了多了一步密钥校验的过程，HTTP 协议里的那些过程都不会少。 不过上面的过程中只包含了 HTTPS 的单向认证，也就是客户端验证服务端的证书，这也是最常见的场景。不过在更加严格要求通信安全的情况下，也可以启用双向认证，双方互相验证证书。 通过上面的整个过程，我们可以看出，HTTPS 协议并不是一个新的协议，它只是 HTTP 协议与一些加密算法的组合，用来保证通信的安全。 虽然上面介绍的非对称加密方式，在现在看来是完美不可解的，但未来谁知道呢？正所谓“道高一尺魔高一丈”，加密安全路上永无尽头。小结加密分对称加密和非对称加密。对称加密效率高，但存在密钥传输的问题；非对称加密可以解决密钥传输的问题，但效率较低。非对称加密需要通过证书和权威机构来验证公钥的合法性。HTTPS 是综合了对称加密和非对称加密算法的 HTTP 协议。既保证了传输安全，也保证了传输效率。参考：百度百科 - htps 词条；刘超 - 趣谈网络协议系列课； ...

系列文章传送门：网络协议 1 - 概述网络协议 2 - IP 是怎么来，又是怎么没的？网络协议 3 - 从物理层到 MAC 层网络协议 4 - 交换机与 VLAN：办公室太复杂，我要回学校网络协议 5 - ICMP 与 ping：投石问路的侦察兵网络协议 6 - 路由协议：敢问路在何方？网络协议 7 - UDP 协议：性善碰到城会玩网络协议 8 - TCP 协议（上）：性恶就要套路深网络协议 9 - TCP协议（下）：聪明反被聪明误网络协议 10 - Socket 编程（上）：实践是检验真理的唯一标准网络协议 11 - Socket 编程（下）：眼见为实耳听为虚 网络协议五层通天路，咱们从物理层、到链路层、网络层、再到传输层，现在又进一步，来到了应用层。这也是我们五层协议里最上面的一层，关于应用层，有太多协议要了解。但要说最有名的，那肯定就是 HTTP 了。 HTTP 协议，几乎是每个人上网用的第一个协议，同时也是很容易被人忽略的协议。 就像 http://blog.muzixizao.com/，是个 URL，叫作统一资源定位符。之所以叫统一，是因为它是有规定格式的。HTTP 称为协议，blog.muzixizao.com 是一个域名，表示互联网的一个位置。有的 URL 会有更详细的位置标识，例如http://blog.muzixizao.com/?p=140 正是因为格式是统一的，所以当你把这样一个字符串输入到浏览器的框里的时候，浏览器才知道如何进行统一处理。HTTP 请求的准备 浏览器会将 blog.muzixizao.com 这个域名发送给 DNS 服务器，让它解析为 IP 地址。关于 DNS 解析的过程，较为复杂，后面会专门介绍。 域名解析成 IP 后，下一步是干嘛呢？ 还记得吗？HTTP 是基于 TCP 协议的，所以接下来就是建立 TCP 连接了。具体的连接过程可点击这里查看。 目前使用的 HTTP 协议大部分都是 1.1.在 1.1 协议里面，默认开启了 Keep-Alive 的，这样建立的 TCP 连接，就可以在多次请求中复用。虽然 HTTP 用了各种方式来解决它存在的问题，但基于TCP 的它，每次建立连接的三次握手以及断开连接的四次挥手，这个过程还是挺费时的。如果好不容易建立了连接，然后做一点儿事情就结束了，未免太浪费了。HTTP 请求的构建 建立了连接以后，浏览器就要发送 HTTP 的请求。请求的格式如下图： 如图，HTTP 的报文大概分为请求行、首部、正文实体三部分。接下来，咱们就来一一认识。请求行 在请求行中，URL 就是 http://blog.muzixizao.com，版本为 HTTP 1.1。这里要说一下的，就是对应的请求方法。有以下几种类型：1）GET 请求 对于访问网页来讲，最常用的类型就是 GET。顾名思义，GET 就是去服务器获取一些资源。对于访问网页来讲，要获取的资源往往是一个页面。其实也有很多其他的格式，比如返回一个 JSON 字符串。当然，具体要返回什么，是由服务端决定的。 例如，在云计算中，如果我们的服务端要提供一个基于 HTTP 协议的 API，获取所有云主机的列表，就会使用 GET 方法请求，返回的可能是一个 JSON 字符串，字符串里面是一个列表，列表里面会有各个云主机的信息。2）POST 请求 另一种类型叫做 POST。它需要主动告诉服务端一些信息，而非获取。而要告诉服务端的信息，一般都放在正文里面。正文里有各种各样的格式，最常见的的就是 JSON了。 例如，我们平时的支付场景，客户端就需要把 “我是谁？我要支付多少？我要买什么？” 这样信息告诉服务器，这就需要 POST 方法。 再如，在云计算里，如果我们的服务器，要提供一个基于 HTTP 协议的创建云主机的 API，也会用到 POST 方法。这个时候往往需要将 “我要创建多大的云主机？多少 CPU 和多少内存？多大硬盘？” 这些信息放在 JSON 字符串里面，通过 POST 的方法告诉服务器。 除了上面常见的两种类型，还有一种 PUT 类型，这种类型就是向指定资源位置上传最新内容。但是 HTTP 的服务区往往是不允许上传文件的，所以 PUT 和 POST 就都变成了要传给服务器东西的方法。 在我们的实际使用过程中，PUT 和 POST 还是有区别的。POST 往往是用来创建一个资源，而 PUT 往往是用来更新一个资源。 例如，云主机已经创建好了，想对云主机打一个标签，说明这个云主机是生产环境的，另外一个云主机是测试环境的。我们修改标签的请求往往就是用 PUT 方法。 还有 DELETE 方法。这个是用来删除资源的。首部字段 请求行下面就是首部字段。首部是 key-value 格式，通过冒号分割。这里面，往往保存了一些非常重要的字段。Accpet-Charset：客户端可以接受的字符集。防止传过来的字符串客户端不支持，从而出现乱码；Content-Type：正文格式。我们进行 POST 请求时，如果正文是 JSON，我们就应该将这个值设置为 application/json；缓存字段 Cache-Control、If-Modified-Since。 这里重点认识下缓存字段。为什么要使用缓存呢？这是因为一个非常大的页面有很多东西。 例如，我们浏览一个商品的详情，里面有商品的价格、库存、展示图片、使用手册等待。 商品的展示图片会保持较长时间不变，而库存胡一根筋用户购买情况经常改变。如果图片非常大，而库存数非常小，如果我们每次要更新数据的时候都要刷新整个页面，对于服务器的压力也会很大。 对于这种高并发场景下的系统，在真正的业务逻辑之前，都需要有个接入层，将这些静态资源的请求拦在最外面。架构就像下图： 其中 DNS、CDN 会在后面的章节详细说明。这里咱们就先来了解下 Nginx 这一层。它是如果处理 HTTP 协议呢？对于静态资源，有 Vanish 缓存层，当缓存过期的时候，才会访问真正的 Tomcat 应用集群。 在 HTTP 头里面，Cache-Control 是用来控制缓存的。当客户端发送的请求中包含 max-age 指令时，如果判定缓存层中，资源的缓存时间数值比指定时间的数值校，那么客户端可以接受缓存的资源；当指定 max-age 值为 0，那么缓存层通常需要将请求转发给应用集群。 另外，If-Modified-Since 也是关于缓存的字段，这个字段是说，如果服务器的资源在某个时间之后更新了，那么客户端就应该下载最新的资源；如果没有更新，服务端会返回“304 Not Modified” 的响应，那客户端就不用下载了，也会节省带宽。 到此，我们拼凑起了 HTTP 请求的报文格式，接下来，浏览器会把它交给传输层。HTTP 请求的发送 HTTP 协议是基于 TCP 协议的，所以它是以面向连接的方式发送请求，通过 stream 二进制流的方式传给对方。当然，到了 TCP 层，它会把二进制流变成一个个的报文段发送给服务器。 在发送给每个报文段的时候，都需要对方有一个回应 ACK，来保证报文可靠地到达了地方。如果没有回应，那么 TCP 这一层会重新传输，直到可以到达。同一个包有可能被传了好多次，但是 HTTP 这一层不需要知道这一点，因为是 TCP 这一层在埋头苦干。而后续传输过程如下：TCP 层封装目标地址和源地址。TCP 层发送每一个报文的时候，都需要加上自己的地址和它想要去的地址，将这两个信息放到 IP 头里面，交给 IP 层进行传输。IP 层获取 MAC 头。IP 层需要查看目标地址和自己是否在同一个局域网。如果是，就发送 ARP 协议来请求这个目标地址对应的 MAC 地址，然后将源 MAC 和目标 MAC 放入 MAC 头，发送出去；如果不在同一个局域网，就需要发送到网关，这里也要通过 ARP 协议来获取网关的 MAC 地址，然后将源 MAC 和网关 MAC 放入 MAC 头，发送出去。网关转发。网关收到包发现 MAC 符合，取出目标 IP 地址，根据路由协议找到下一跳的路由器，获取下一跳路由器的 MAC 地址，将包发给下一跳路由器。数据包到达目标地址的局域网。通过 ARP 协议获取目标地址的 MAC 地址，将包发出去。目标地址检查信息，返回 ACK。目标机器发现数据包中的 MAC 地址及 IP 地址都和本机匹配，就根据 IP 头中的协议类型，知道是 TCP 协议，解析 TCP 的头，获取序列号。判断序列号是否是本机需要的，如果是，就放入缓存中然后返回一个 ACK，如果不是就丢弃。根据端口号将数据包发送到指定应用。TCP 头里面还有端口号，HTTP 的服务器正在监听这个端口号。于是，目标机器自然指定是 HTTP 服务器这个进程想要这个包，就把数据包发给 HTTP 服务器。HTTP 服务器处理请求。HTTP 服务器根据请求信息进行处理，并返回数据给客户端。HTTP 返回的构建 HTTP 的返回报文也是有一定格式的，如下图：状态行包含状态码和短语。状态码反应 HTTP 请求的结果。200 是大吉大利；404 则是我们最不想见到的，也就是服务端无法响应这个请求。短语中会说明出错原因。首部 key-value。这里常用的有以下字段：Retry-After：客户端应该在多长时间后再次尝试连接；Content-Type：返回数据格式 构造好了返回的 HTTP 报文，接下来就是把这个报文发送出去。当然，还是交给 Socket 去发送，交给 TCP，让 TCP 返回的 HTML 分成一个个小的数据段，并且保证每一段都安全到达。这些小的数据段会加上 TCP 头，然后交给 IP 层，沿着来时的路反向走一遍。虽然不一定是完全相同的路径，但是逻辑过程是一样的，一直到达客户端。 客户端取出数据后 ，会根据端口号交给指定的程序，这时候就是我们的浏览器出马的时候。 浏览器拿到了 HTTP 报文，发现返回 200，一切正常，就从正文中将 HTML 拿出来，展示出一个炫酷吊炸天的网页。 以上就是正常的 HTTP 请求与返回的完整过程。HTTP 2.0 上面提到了，现在用到 HTTP 大多是 1.1 版本，而 HTTP 2.0 在 1.1 的基础上进行了一些优化，以期解决一些问题。 HTTP 1.1 在应用层以纯文本的形式进行通信。每次通信都要带完整的 HTTP 头，而且不考虑 pipeline 模式的话，每次的过程都要像上面描述的那样一去一回。显然，在效率上会存在问题。 为了解决这些问题，HTTP 2.0 会对 HTTP 头进行一定的压缩，将原来每次都要携带的大量 key-value 对在两端建立一个索引表，对相同的头只发送索引表中的索引。 另外，HTTP 2.0 协议将一个 TCP 连接切分成多个流，每个流都有自己的 ID，而且流可以是客户端发给服务端，也可以是服务端发给客户端，它其实只是个虚拟的通道，除此之外，它还有优先级。 HTTP 2.0 将所有的传输信息分割成更小的消息和帧，并对它们采用二进制格式编码。常见的帧有 Header 帧，用于传输 Header 内容，并且会开启一个新的流。还有 Data 帧，用来传输正文实体，并且多个 Data 帧属于同个流。 通过这两种机制，HTTP 2.0 的客户端可以将多个请求分到不同的流中， 然后将请求内容拆分成帧，进行二进制传输。这些帧可以打散乱序发送，然后根据帧首部的流标识符重新组装，并且可以根据优先级，决定先处理哪个流的数据。 针对 HTTP 2.0，我们来看一个例子。 假设我们有一个页面要发送三个独立的请求，一个获取 CSS、一个获取 JS、一个获取图片 jsg。如果使用 HTTP 1.1，这三个请求就是串行的，但是如果使用 HTTP 2.0，就可以在一个连接里，客户端和服务端同时反思多个请求和回应，而且不用按照顺序一对一对应。 如上图。HTTP 2.0 其实是将三个请求变成三个流，将数据分成帧，乱序发送到一个 TCP 连接中。 HTTP 2.0 成功解决了 HTTP 1.1 的队首阻塞问题。同时，也不需要通过 HTTP 1.x 的 pipeline 机制用多条 TCP 连接来实现并行请求与响应，减少了 TCP 连接数对服务器性能的影响，加快页面组件的传输速度。 HTTP 2.0 虽然大大增加了并发性，但由于 TCP 协议的按序处理的特性，还是会出现阻塞的问题。 还记得咱们之前说过的 QUIC 协议吗？这时候就是它登场的时候了。 它用以下四个机制，解决了 TCP 存在的一些问题。机制一：自定义连接机制 我们知道，一条 TCP 连接是由四元组标识的。一旦一个元素发生变化，就需要端口重连。这在移动互联网的情况下，当我们切换网络或者信号不稳定时，都会导致重连，从而增加时延。 TCP 没办法解决上述问题，但是 QUCI 基于 UDP 协议，就可以在自己的逻辑里面维护连接的机制，不再以四元组标识，而是以一个 64 位的随机数作为标识 ID，而且 UDP 是无连接的，只要 ID 不变，就不需要重新建立连接。机制二：自定义重传机制 TCP 为了保证可靠性，通过使用序号和应答机制，来解决顺序问题和丢包问题。 任何一个序号的包发出去，都要在一定时间内得到应答，否则就会超时重发。这个超时时间就是通过采样往返时间 RTT 不断调整的。其实，这个超时时间的采样是不太准确的。 如上图。发送一个包，序号为 100，超时后，再发送一个 100。然后收到了一个 ACK101。这个时候客户端知道服务器已经收到了 100，但是往返时间怎么计算呢？是 ACK 到达时间减去后一个 100 发送的时间，还是减去前一个 100 发送的时间呢？前者把时间算短了，后者把时间算长了。 QUIC 也有一个序列号，是完全递增的。任何一个包发送一次后，下一次序列号就要加一。像我们上面的例子，在 QUIC 协议中，100 的包没有返回，再次发送时，序号就是 101 了，如果返回是 ACK100，就是对第一个包的响应，如果返回 ACK101，就是对第二个包的响应，RTT 时间计算相对准确，过程如下图： 上面的过程中，有的童鞋可能会问了，两个序号不一样的包，服务器怎么知道是同样的内容呢？没错，这确实是个问题。为了解决这个问题，QUIC 协议定义了一个 Offset 的概念。 QUIC 既然是面向连接的，也就像 TCP 一样，是一个数据流。，发送的数据在这个流里面都有个偏移量 Offset，可以通过 Offset 查看数据发送到了那里，这样只要这个 Offset 的包没有来，就要重发。如果来了，就按照 Offset 拼接成一个流。机制三：无阻塞的多路复用 有了自定义的连接和重传机制，我们就可以解决上面 HTTP 2.0 的多路复用问题。 同 HTTP 2.0 一样，同一条 QUIC 连接上可以创建多个 stream，来发送多个 HTTP 请求。更棒的是，QUIC 是基于 UDP 的，一个连接上的多个 stream 之间没有依赖。这样，假如 stream2 丢了一个 UDP 包，后面跟着 stream3 的一个 UDP 包，虽然 stream2 的那个包需要重传，但是 stream3 的包无需等待，就可以发给用户。机制四：自定义流量控制 TCP 的流量控制是通过滑动窗口协议。QUIC 的流量控制也是通过 window_update，来告诉对端它可以接受的字节数。但是 QUIC 的窗口是适应自己的多路复用机制的，不但在一个连接上控制窗口，还在一个连接中的每个 stream 控制窗口。 还记得吗？在 TCP 协议中，接收端的窗口的起始点是下一个要接收并且 ACK 的包，即便后来的包都到了，放在缓存里面，窗口也不能右移，因为 TCP 的 ACK 机制是基于序列号的累计应答，一旦 ACK 一个序列号，就说明前面的都到了，所以只要前面的没到，后面的即使到了也不能 ACK，就会导致后面的到了，也有可能超时重传，浪费带宽。 QUIC 的 ACK 是基于 offset 的，每个 offset 的包来了，进了缓存，就可以应答，应答后就不会重发，中间的空档会等待到来或者重发即可，而窗口的起始位置为当前收到的最大 offset，从这个 offset 到当前的 stream 所能容纳的最大缓存，是真正的窗口大小，显然，这样更加准确。 另外，还有整个连接的窗口，需要对于所有的 stream 的窗口做一个统计。小结HTTP 协议虽然很常用，也很复杂，我们只需要重点记住 GET、POST、PUT、DELETE 这几个方法，以及重要的首部字段；HTTP 2.0 通过头压缩、分帧、二进制编码、多路复用等技术提升性能；QUIC 协议通过基于 UDP 自定义的类似 TCP 的连接、重试、多路复用、流量控制技术，进一步提升性能。参考：The TCP/IP Guide；百度百科 - HTTP 词条；刘超 - 趣谈网络协议系列课； ...

一篇文章带你熟悉 TCP/IP协议-（一）-https://segmentfault.com/a/11…一篇文章带你熟悉 TCP/IP协议-（二）-https://segmentfault.com/a/11…一篇文章带你熟悉 TCP/IP协议-（三）-https://segmentfault.com/a/11…四、网络层中的 IP 协议IP（IPv4、IPv6）相当于 OSI 参考模型中的第3层——网络层。网络层的主要作用是“实现终端节点之间的通信”。这种终端节点之间的通信也叫“点对点通信”。网络的下一层——数据链路层的主要作用是在互连同一种数据链路的节点之间进行包传递。而一旦跨越多种数据链路，就需要借助网络层。网络层可以跨越不同的数据链路，即使是在不同的数据链路上也能实现两端节点之间的数据包传输。IP 大致分为三大作用模块，它们是 IP 寻址、路由（最终节点为止的转发）以及 IP 分包与组包。1. IP 地址1.1 IP 地址概述在计算机通信中，为了识别通信对端，必须要有一个类似于地址的识别码进行标识。在数据链路中的 MAC 地址正是用来标识同一个链路中不同计算机的一种识别码。作为网络层的 IP ,也有这种地址信息，一般叫做 IP 地址。IP 地址用于在“连接到网络中的所有主机中识别出进行通信的目标地址”。因此，在 TCP/IP 通信中所有主机或路由器必须设定自己的 IP 地址。不论一台主机与哪种数据链路连接，其 IP 地址的形式都保持不变。IP 地址（IPv4 地址）由32位正整数来表示。IP 地址在计算机内部以二进制方式被处理。然而，由于我们并不习惯于采用二进制方式，我们将32位的 IP 地址以每8位为一组，分成4组，每组以 “.” 隔开，再将每组数转换成十进制数。如下：1.2 IP 地址由网络和主机两部分标识组成如下图，网络标识在数据链路的每个段配置不同的值。网络标识必须保证相互连接的每个段的地址不相重复。而相同段内相连的主机必须有相同的网络地址。IP 地址的“主机标识”则不允许在同一个网段内重复出现。由此，可以通过设置网络地址和主机地址，在相互连接的整个网络中保证每台主机的 IP 地址都不会相互重叠。即 IP 地址具有了唯一性。如下图，IP 包被转发到途中某个路由器时，正是利用目标 IP 地址的网络标识进行路由。因为即使不看主机标识，只要一见到网络标识就能判断出是否为该网段内的主机。1.3 IP 地址的分类IP 地址分为四个级别，分别为A类、B类、C类、D类。它根据 IP 地址中从第 1 位到第 4 位的比特列对其网络标识和主机标识进行区分。A 类 IP 地址是首位以 “0” 开头的地址。从第 1 位到第 8 位是它的网络标识。用十进制表示的话，0.0.0.0127.0.0.0 是 A 类的网络地址。A 类地址的后 24 位相当于主机标识。因此，一个网段内可容纳的主机地址上限为16,777,214个。B 类 IP 地址是前两位 “10” 的地址。从第 1 位到第 16 位是它的网络标识。用十进制表示的话，128.0.0.0191.255.0.0 是 B 类的网络地址。B 类地址的后 16 位相当于主机标识。因此，一个网段内可容纳的主机地址上限为65,534个。C 类 IP 地址是前三位为 “110” 的地址。从第 1 位到第 24 位是它的网络标识。用十进制表示的话，192.0.0.0223.255.255.0 是 C 类的网络地址。C 类地址的后 8 位相当于主机标识。因此，一个网段内可容纳的主机地址上限为254个。D 类 IP 地址是前四位为 “1110” 的地址。从第 1 位到第 32 位是它的网络标识。用十进制表示的话，224.0.0.0239.255.255.255 是 D 类的网络地址。D 类地址没有主机标识，常用于多播。在分配 IP 地址时关于主机标识有一点需要注意。即要用比特位表示主机地址时，不可以全部为 0 或全部为 1。因为全部为 0 只有在表示对应的网络地址或 IP 地址不可以获知的情况下才使用。而全部为 1 的主机通常作为广播地址。因此，在分配过程中，应该去掉这两种情况。这也是为什么 C 类地址每个网段最多只能有 254（ 28 - 2 = 254）个主机地址的原因。1.4 广播地址广播地址用于在同一个链路中相互连接的主机之间发送数据包。将 IP 地址中的主机地址部分全部设置为 1，就成了广播地址。广播分为本地广播和直接广播两种。在本网络内的广播叫做本地广播；在不同网络之间的广播叫做直接广播。1.5 IP 多播多播用于将包发送给特定组内的所有主机。由于其直接使用 IP 地址，因此也不存在可靠传输。相比于广播，多播既可以穿透路由器，又可以实现只给那些必要的组发送数据包。请看下图：多播使用 D 类地址。因此，如果从首位开始到第 4 位是 “1110”，就可以认为是多播地址。而剩下的 28 位可以成为多播的组编号。此外， 对于多播，所有的主机（路由器以外的主机和终端主机）必须属于 224.0.0.1 的组，所有的路由器必须属于 224.0.0.2 的组。1.6 子网掩码现在一个 IP 地址的网络标识和主机标识已不再受限于该地址的类别，而是由一个叫做“子网掩码”的识别码通过子网网络地址细分出比 A 类、B 类、C 类更小粒度的网络。这种方式实际上就是将原来 A 类、B 类、C 类等分类中的主机地址部分用作子网地址，可以将原网络分为多个物理网络的一种机制。子网掩码用二进制方式表示的话，也是一个 32 位的数字。它对应 IP 地址网络标识部分的位全部为 “1”，对应 IP 地址主机标识的部分则全部为 “0”。由此，一个 IP 地址可以不再受限于自己的类别，而是可以用这样的子网掩码自由地定位自己的网络标识长度。当然，子网掩码必须是 IP 地址的首位开始连续的 “1”。对于子网掩码，目前有两种表示方式。第一种是，将 IP 地址与子网掩码的地址分别用两行来表示。以 172.20.100.52 的前 26 位是网络地址的情况为例，如下：第二种表示方式是，在每个 IP 地址后面追加网络地址的位数用 “/ ” 隔开，如下：另外，在第二种方式下记述网络地址时可以省略后面的 “0” 。例如：172.20.0.0/26 跟 172.20/26 其实是一个意思。2. 路由发送数据包时所使用的地址是网络层的地址，即 IP 地址。然而仅仅有 IP 地址还不足以实现将数据包发送到对端目标地址，在数据发送过程中还需要类似于“指明路由器或主机”的信息，以便真正发往目标地址。保存这种信息的就是路由控制表。该路由控制表的形成方式有两种：一种是管理员手动设置，另一种是路由器与其他路由器相互交换信息时自动刷新。前者也叫做静态路由控制，而后者叫做动态路由控制。IP 协议始终认为路由表是正确的。然后，IP 本身并没有定义制作路由控制表的协议。即 IP 没有制作路由控制表的机制。该表示由一个叫做“路由协议”的协议制作而成。2.1 IP 地址与路由控制IP 地址的网络地址部分用于进行路由控制。路由控制表中记录着网络地址与下一步应该发送至路由器的地址。在发送 IP 包时，首先要确定 IP 包首部中的目标地址，再从路由控制表中找到与该地址具有相同网络地址的记录，根据该记录将 IP 包转发给相应的下一个路由器。如果路由控制表中存在多条相同网络地址的记录，就选择一个最为吻合的网络地址。3. IP 分包与组包每种数据链路的最大传输单元（MTU）都不尽相同，因为每个不同类型的数据链路的使用目的不同。使用目的不同，可承载的 MTU 也就不同。任何一台主机都有必要对 IP 分片进行相应的处理。分片往往在网络上遇到比较大的报文无法一下子发送出去时才会进行处理。经过分片之后的 IP 数据报在被重组的时候，只能由目标主机进行。路由器虽然做分片但不会进行重组。3.1 路径 MTU 发现分片机制也有它的不足。如路由器的处理负荷加重之类。因此，只要允许，是不希望由路由器进行 IP 数据包的分片处理的。为了应对分片机制的不足，“路径 MTU 发现” 技术应运而生。路径 MTU 指的是，从发送端主机到接收端主机之间不需要分片是最大 MTU 的大小。即路径中存在的所有数据链路中最小的 MTU 。进行路径 MTU 发现，就可以避免在中途的路由器上进行分片处理，也可以在 TCP 中发送更大的包。4. IPv6IPv6（IP version 6）是为了根本解决 IPv4 地址耗尽的问题而被标准化的网际协议。IPv4 的地址长度为 4 个 8 位字节，即 32 比特。而 IPv6 的地址长度则是原来的 4 倍，即 128 比特，一般写成 8 个 16 位字节。4.1 IPv6 的特点IP 得知的扩大与路由控制表的聚合。性能提升。包首部长度采用固定的值（40字节），不再采用首部检验码。简化首部结构，减轻路由器负担。路由器不再做分片处理。支持即插即用功能。即使没有DHCP服务器也可以实现自动分配 IP 地址。采用认证与加密功能。应对伪造 IP 地址的网络安全功能以及防止线路窃听的功能。多播、Mobile IP 成为扩展功能。4.2 IPv6 中 IP 地址的标记方法一般人们将 128 比特 IP 地址以每 16 比特为一组，每组用冒号（“：”）隔开进行标记。而且如果出现连续的 0 时还可以将这些 0 省略，并用两个冒号（“：：”）隔开。但是，一个 IP 地址中只允许出现一次两个连续的冒号。4.3 IPv6 地址的结构IPv6 类似 IPv4，也是通过 IP 地址的前几位标识 IP 地址的种类。在互联网通信中，使用一种全局的单播地址。它是互联网中唯一的一个地址，不需要正式分配 IP 地址。4.4 全局单播地址全局单播地址是指世界上唯一的一个地址。它是互联网通信以及各个域内部通信中最为常用的一个 IPv6 地址。格式如下图所示，现在 IPv6 的网络中所使用的格式为，n = 48，m = 16 以及 128 - n - m = 64。即前 64 比特为网络标识，后 64 比特为主机标识。4.5 链路本地单播地址链路本地单播地址是指在同一个数据链路内唯一的地址。它用于不经过路由器，在同一个链路中的通信。通常接口 ID 保存 64 比特版的 MAC 地址。4.6 唯一本地地址唯一本地地址是不进行互联网通信时所用的地址。唯一本地地址虽然不会与互联网连接，但是也会尽可能地随机生成一个唯一的全局 ID。L 通常被置为 1全局 ID 的值随机决定子网 ID 是指该域子网地址接口 ID 即为接口的 ID4.7 IPv6 分段处理IPv6 的分片处理只在作为起点的发送端主机上进行，路由器不参与分片。IPv6 中最小 MTU 为 1280 字节，因此，在嵌入式系统中对于那些有一定系统资源限制的设备来说，不需要进行“路径 MTU 发现”，而是在发送 IP 包时直接以 1280 字节为单位分片送出。4.8 IP 首部（暂略）5. IP 协议相关技术IP 旨在让最终目标主机收到数据包，但是在这一过程中仅仅有 IP 是无法实现通信的。必须还有能够解析主机名称和 MAC 地址的功能，以及数据包在发送过程中异常情况处理的功能。5.1 DNS我们平常在访问某个网站时不适用 IP 地址，而是用一串由罗马字和点号组成的字符串。而一般用户在使用 TCP/IP 进行通信时也不使用 IP 地址。能够这样做是因为有了 DNS （Domain Name System）功能的支持。DNS 可以将那串字符串自动转换为具体的 IP 地址。这种 DNS 不仅适用于 IPv4，还适用于 IPv6。5.2 ARP只要确定了 IP 地址，就可以向这个目标地址发送 IP 数据报。然而，在底层数据链路层，进行实际通信时却有必要了解每个 IP 地址所对应的 MAC 地址。ARP 是一种解决地址问题的协议。以目标 IP 地址为线索，用来定位下一个应该接收数据分包的网络设备对应的 MAC 地址。不过 ARP 只适用于 IPv4，不能用于 IPv6。IPv6 中可以用 ICMPv6 替代 ARP 发送邻居探索消息。RARP 是将 ARP 反过来，从 MAC 地址定位 IP 地址的一种协议。5.3 ICMPICMP 的主要功能包括，确认 IP 包是否成功送达目标地址，通知在发送过程当中 IP 包被废弃的具体原因，改善网络设置等。IPv4 中 ICMP 仅作为一个辅助作用支持 IPv4。也就是说，在 IPv4 时期，即使没有 ICMP，仍然可以实现 IP 通信。然而，在 IPv6 中，ICMP 的作用被扩大，如果没有 ICMPv6，IPv6 就无法进行正常通信。5.4 DHCP如果逐一为每一台主机设置 IP 地址会是非常繁琐的事情。特别是在移动使用笔记本电脑、只能终端以及平板电脑等设备时，每移动到一个新的地方，都要重新设置 IP 地址。于是，为了实现自动设置 IP 地址、统一管理 IP 地址分配，就产生了 DHCP（Dynamic Host Configuration Protocol）协议。有了 DHCP，计算机只要连接到网络，就可以进行 TCP/IP 通信。也就是说，DHCP 让即插即用变得可能。DHCP 不仅在 IPv4 中，在 IPv6 中也可以使用。5.5 NATNAT（Network Address Translator）是用于在本地网络中使用私有地址，在连接互联网时转而使用全局 IP 地址的技术。除转换 IP 地址外，还出现了可以转换 TCP、UDP 端口号的 NAPT（Network Address Ports Translator）技术，由此可以实现用一个全局 IP 地址与多个主机的通信。NAT（NAPT）实际上是为正在面临地址枯竭的 IPv4 而开发的技术。不过，在 IPv6 中为了提高网络安全也在使用 NAT，在 IPv4 和 IPv6 之间的相互通信当中常常使用 NAT-PT。5.6 IP 隧道如上图的网络环境中，网络 A 与网络 B 之间无法直接进行通信，为了让它们之间正常通信，这时必须得采用 IP 隧道的功能。IP 隧道可以将那些从网络 A 发过来的 IPv6 的包统合为一个数据，再为之追加一个 IPv4 的首部以后转发给网络 C。一般情况下，紧接着 IP 首部的是 TCP 或 UDP 的首部。然而，现在的应用当中“ IP 首部的后面还是 IP 首部”或者“ IP 首部的后面是 IPv6 ...

三、传输层中的 TCP 和 UDPTCP/IP 中有两个具有代表性的传输层协议，分别是 TCP 和 UDP。TCP 是面向连接的、可靠的流协议。流就是指不间断的数据结构，当应用程序采用 TCP 发送消息时，虽然可以保证发送的顺序，但还是犹如没有任何间隔的数据流发送给接收端。TCP 为提供可靠性传输，实行“顺序控制”或“重发控制”机制。此外还具备“流控制（流量控制）”、“拥塞控制”、提高网络利用率等众多功能。UDP 是不具有可靠性的数据报协议。细微的处理它会交给上层的应用去完成。在 UDP 的情况下，虽然可以确保发送消息的大小，却不能保证消息一定会到达。因此，应用有时会根据自己的需要进行重发处理。TCP 和 UDP 的优缺点无法简单地、绝对地去做比较：TCP 用于在传输层有必要实现可靠传输的情况；而在一方面，UDP 主要用于那些对高速传输和实时性有较高要求的通信或广播通信。TCP 和 UDP 应该根据应用的目的按需使用。1. 端口号数据链路和 IP 中的地址，分别指的是 MAC 地址和 IP 地址。前者用来识别同一链路中不同的计算机，后者用来识别 TCP/IP 网络中互连的主机和路由器。在传输层也有这种类似于地址的概念，那就是端口号。端口号用来识别同一台计算机中进行通信的不同应用程序。因此，它也被称为程序地址。1.1 根据端口号识别应用一台计算机上同时可以运行多个程序。传输层协议正是利用这些端口号识别本机中正在进行通信的应用程序，并准确地将数据传输。1.2 通过 IP 地址、端口号、协议号进行通信识别仅凭目标端口号识别某一个通信是远远不够的。① 和② 的通信是在两台计算机上进行的。它们的目标端口号相同，都是80。这里可以根据源端口号加以区分。③ 和 ① 的目标端口号和源端口号完全相同，但它们各自的源 IP 地址不同。此外，当 IP 地址和端口号全都一样时，我们还可以通过协议号来区分（TCP 和 UDP）。1.3 端口号的确定标准既定的端口号：这种方法也叫静态方法。它是指每个应用程序都有其指定的端口号。但并不是说可以随意使用任何一个端口号。例如 HTTP、FTP、TELNET 等广为使用的应用协议中所使用的端口号就是固定的。这些端口号被称为知名端口号，分布在 01023 之间；除知名端口号之外，还有一些端口号被正式注册，它们分布在 102449151 之间，不过这些端口号可用于任何通信用途。时序分配法：服务器有必要确定监听端口号，但是接受服务的客户端没必要确定端口号。在这种方法下，客户端应用程序完全可以不用自己设置端口号，而全权交给操作系统进行分配。动态分配的端口号范围在 49152~65535 之间。1.4 端口号与协议端口号由其使用的传输层协议决定。因此，不同的传输层协议可以使用相同的端口号。此外，那些知名端口号与传输层协议并无关系。只要端口一致都将分配同一种应用程序进行处理。2. UDPUDP 不提供复杂的控制机制，利用 IP 提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻，立即按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况，UDP 也无法进行流量控制等避免网络拥塞行为。此外，传输途中出现丢包，UDP 也不负责重发。甚至当包的到达顺序出现乱序时也没有纠正的功能。如果需要以上的细节控制，不得不交由采用 UDP 的应用程序去处理。UDP 常用于一下几个方面：1.包总量较少的通信（DNS、SNMP等）；2.视频、音频等多媒体通信（即时通信）；3.限定于 LAN 等特定网络中的应用通信；4.广播通信（广播、多播）。3. TCPTCP 与 UDP 的区别相当大。它充分地实现了数据传输时各种控制功能，可以进行丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。而这些在 UDP 中都没有。此外，TCP 作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。根据 TCP 的这些机制，在 IP 这种无连接的网络上也能够实现高可靠性的通信（ 主要通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现）。3.1 三次握手（重点）TCP 提供面向有连接的通信传输。面向有连接是指在数据通信开始之前先做好两端之间的准备工作。所谓三次握手是指建立一个 TCP 连接时需要客户端和服务器端总共发送三个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发。下面来看看三次握手的流程图：第一次握手：客户端将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给服务器端，客户端进入SYN_SENT状态，等待服务器端确认。第二次握手：服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务器端将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给客户端以确认连接请求，服务器端进入SYN_RCVD状态。第三次握手：客户端收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务器端，服务器端检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器端进入ESTABLISHED状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。3.2 四次挥手（重点）四次挥手即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。由于TCP连接是全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。下面来看看四次挥手的流程图：中断连接端可以是客户端，也可以是服务器端。第一次挥手：客户端发送一个FIN=M，用来关闭客户端到服务器端的数据传送，客户端进入FIN_WAIT_1状态。意思是说"我客户端没有数据要发给你了"，但是如果你服务器端还有数据没有发送完成，则不必急着关闭连接，可以继续发送数据。第二次挥手：服务器端收到FIN后，先发送ack=M+1，告诉客户端，你的请求我收到了，但是我还没准备好，请继续你等我的消息。这个时候客户端就进入FIN_WAIT_2 状态，继续等待服务器端的FIN报文。第三次挥手：当服务器端确定数据已发送完成，则向客户端发送FIN=N报文，告诉客户端，好了，我这边数据发完了，准备好关闭连接了。服务器端进入LAST_ACK状态。第四次挥手：客户端收到FIN=N报文后，就知道可以关闭连接了，但是他还是不相信网络，怕服务器端不知道要关闭，所以发送ack=N+1后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。服务器端收到ACK后，就知道可以断开连接了。客户端等待了2MSL后依然没有收到回复，则证明服务器端已正常关闭，那好，我客户端也可以关闭连接了。最终完成了四次握手。上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况，具体流程如下图：3.3 通过序列号与确认应答提高可靠性在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个已收到消息的通知。这个消息叫做确认应答（ACK）。当发送端将数据发出之后会等待对端的确认应答。如果有确认应答，说明数据已经成功到达对端。反之，则数据丢失的可能性很大。在一定时间内没有等待到确认应答，发送端就可以认为数据已经丢失，并进行重发。由此，即使产生了丢包，仍然能够保证数据能够到达对端，实现可靠传输。未收到确认应答并不意味着数据一定丢失。也有可能是数据对方已经收到，只是返回的确认应答在途中丢失。这种情况也会导致发送端误以为数据没有到达目的地而重发数据。此外，也有可能因为一些其他原因导致确认应答延迟到达，在源主机重发数据以后才到达的情况也屡见不鲜。此时，源主机只要按照机制重发数据即可。对于目标主机来说，反复收到相同的数据是不可取的。为了对上层应用提供可靠的传输，目标主机必须放弃重复的数据包。为此我们引入了序列号。序列号是按照顺序给发送数据的每一个字节（8位字节）都标上号码的编号。接收端查询接收数据 TCP 首部中的序列号和数据的长度，将自己下一步应该接收的序列号作为确认应答返送回去。通过序列号和确认应答号，TCP 能够识别是否已经接收数据，又能够判断是否需要接收，从而实现可靠传输。3.4 重发超时的确定重发超时是指在重发数据之前，等待确认应答到来的那个特定时间间隔。如果超过这个时间仍未收到确认应答，发送端将进行数据重发。最理想的是，找到一个最小时间，它能保证“确认应答一定能在这个时间内返回”。TCP 要求不论处在何种网络环境下都要提供高性能通信，并且无论网络拥堵情况发生何种变化，都必须保持这一特性。为此，它在每次发包时都会计算往返时间及其偏差。将这个往返时间和偏差时间相加，重发超时的时间就是比这个总和要稍大一点的值。在 BSD 的 Unix 以及 Windows 系统中，超时都以0.5秒为单位进行控制，因此重发超时都是0.5秒的整数倍。不过，最初其重发超时的默认值一般设置为6秒左右。数据被重发之后若还是收不到确认应答，则进行再次发送。此时，等待确认应答的时间将会以2倍、4倍的指数函数延长。此外，数据也不会被无限、反复地重发。达到一定重发次数之后，如果仍没有任何确认应答返回，就会判断为网络或对端主机发生了异常，强制关闭连接。并且通知应用通信异常强行终止。3.5 以段为单位发送数据在建立 TCP 连接的同时，也可以确定发送数据包的单位，我们也可以称其为“最大消息长度”（MSS）。最理想的情况是，最大消息长度正好是 IP 中不会被分片处理的最大数据长度。TCP 在传送大量数据时，是以 MSS 的大小将数据进行分割发送。进行重发时也是以 MSS 为单位。MSS 在三次握手的时候，在两端主机之间被计算得出。两端的主机在发出建立连接的请求时，会在 TCP 首部中写入 MSS 选项，告诉对方自己的接口能够适应的 MSS 的大小。然后会在两者之间选择一个较小的值投入使用。3.6 利用窗口控制提高速度TCP 以1个段为单位，每发送一个段进行一次确认应答的处理。这样的传输方式有一个缺点，就是包的往返时间越长通信性能就越低。为解决这个问题，TCP 引入了窗口这个概念。确认应答不再是以每个分段，而是以更大的单位进行确认，转发时间将会被大幅地缩短。也就是说，发送端主机，在发送了一个段以后不必要一直等待确认应答，而是继续发送。如下图所示：窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。上图中窗口大小为4个段。这个机制实现了使用大量的缓冲区，通过对多个段同时进行确认应答的功能。3.7 滑动窗口控制上图中的窗口内的数据即便没有收到确认应答也可以被发送出去。不过，在整个窗口的确认应答没有到达之前，如果其中部分数据出现丢包，那么发送端仍然要负责重传。为此，发送端主机需要设置缓存保留这些待被重传的数据，直到收到他们的确认应答。在滑动窗口以外的部分包括未发送的数据以及已经确认对端已收到的数据。当数据发出后若如期收到确认应答就可以不用再进行重发，此时数据就可以从缓存区清除。收到确认应答的情况下，将窗口滑动到确认应答中的序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制也别称为滑动窗口控制。3.8 窗口控制中的重发控制在使用窗口控制中， 出现丢包一般分为两种情况：① 确认应答未能返回的情况。在这种情况下，数据已经到达对端，是不需要再进行重发的，如下图：② 某个报文段丢失的情况。接收主机如果收到一个自己应该接收的序列号以外的数据时，会针对当前为止收到数据返回确认应答。如下图所示，当某一报文段丢失后，发送端会一直收到序号为1001的确认应答，因此，在窗口比较大，又出现报文段丢失的情况下，同一个序列号的确认应答将会被重复不断地返回。而发送端主机如果连续3次收到同一个确认应答，就会将其对应的数据进行重发。这种机制比之前提到的超时管理更加高效，因此也被称为高速重发控制。 ...

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~本文由mariolu发表于云+社区专栏序言目前HTTP/2.0（简称h2）已经在广泛使用（截止2018年8月根据Alexa流行度排名的头部1千万网站中，h2占比约29%,https://w3techs.com/technolog…）。写此文章的目的是：h2作为较新的技术，并逐渐占有率广泛，虽然目前有更新的QUIC，但其实现思路类似于h2。颠覆以往的HTTP/1.x，H2的创造性的技术值得我们细细品味。此篇文章根据笔者在h2开发经验和思考，向你介绍全面的h2知识以及是非功过。本篇更注重于帮助读者理解h2的设计思路、亦可作为一篇RFC导读或者总结。第一话、追踪溯源图1、HTTP年鉴图早在1991年，伴随WWW诞生之初，HTTP/0.9协议已经提出。HTTP0.9是简单且应用受限的协议。支持去网络主机获取对应路径的资源。但是没有扩展属性。其协议之简单甚至只用下面一个访问谷歌主机的例子概括了HTTP/0.9的全部。如下所示，协议只支持GET，没有http头；响应只能是超文本。telnet google.com 80Connected to x.x.x.xGET /about(Hyper text)(Conection closed)随着人们对富媒体信息的渴望以及浏览器的普及，HTTP/1.0在1996年被提出来。HTTP/1.0的很多特性目前还被广泛使用，但是仍然像HTTP/0.9一样一次请求需要创建一次的tcp连接。随即短短几年时间内，HTTP/1.1以RFC标准形式再次展现在人们眼前。此时的HTTP协议1.1版本已经重新设计了长连接、options请求方法、cache头、upgrade头、range头、transfer-encoding头, 以及pieline(in order)等概念。而我们另一个所熟知的HTTPS的SSL/TLS技术各个版本差不多在后来的十年间逐渐被提出。出于安全考虑，互联网通信间的防火墙路由交换机等设备，这些设备一般仅会开发有限的端口（如80和443）。各种版本的通信协议只能复用这些端口。HTTP1.1的80端口设计了upgrade请求头升级到更高级的协议，而443端口为了避免多消耗个网络RTT，在tls握手过程中使用了NPN/ALPN技术直接在通信之前保持CS两端的协议一致。NPN/ALPN是是TLS协议扩展，其中NPN是Google为实现spdy提出的。由服务端提供可支持的协议，供客户端选择。ALPN则是更接近于HTTP交互的方式，由客户端先发出使用某种协议的请求，由服务端确认是否支持协议。ALPN为了HTTP2诞生做铺垫。另外一个不得不提的是spdy协议。Spdy旨在解决HTTP1.1的线头阻塞问题（后面章节有详细讨论）于2009被google提出。同时分别于2012提出了spdy3.0实现了流控制，2013-2014期间提出了流优先级，server push等概念。Spdy的存在意义更像是http2.0的体验服。它为探索HTTP继续演进道路做了铺垫。第二话、人机交互汇编是效率最高的语言之一，但是又是最晦涩难懂的语言之一。而人脑易懂的编程语言往往牺牲性能作为折衷。简单说，HTTP/1.x协议就是为了人类语言习惯所设计的协议，但是转换成机器执行协议并不是高效的。让我们在回顾下计算机执行解析HTTP1.x的流程。GET / HTTP/1.1<crlf>Host: xxx.aa.com<crlf><crlf>对应的解析伪代码是loop while(! CRLF) read bytes end while if line 1: parse line as Request-Line else if empty line: Break out and We have done else If start with non-whitespace parse header else if space continue with last heade end ifend loop在伪代码解析流程可以看到，肉眼看起来简洁的协议解析起来是这么的费劲。而且在HTTP服务器中还要考虑这种问题：字节行的长度是未知的，也不知道预先分配多大内存。HTTP/2.0使用了计算机易懂的二进制编码信息，而且得向上兼容HTTP的涵义。具体我们来看下他是如何做到的。像大多数通信协议一样，桢是传输最小单位。桢分为数据帧和控制桢。数据帧作为数据的载体，控制桢控制信道的信令。h2桢的通用格式为首部9字节+额外的字符。正如你能想到的那样，桢的第一个部分是描述长度，第二个部分描述了桢的类型，第三个部分描述了标志Flag，第四个部分是唯一序列号。这是所有桢的通用头。通用头紧接的是桢的实体。图4展示了桢的结构。图2、通用桢的格式这样设计有什么好处呢。再来看一下桢的解析流程，你就会发现对计算机来说更简洁。loop read 9 byte payload_Length=first 3 bytes read payload swith type: Take actionend loopHTTP2.0使用header桢表达HTTP header+request line，data桢表达Body。header桢和data桢使用相同的stream id组成一个完整的HTTP请求/响应包。这里的stream描述了一次请求和响应，相当于完成了一次HTTP/1.x的短连接请求和响应。第三话、并行不悖上节讲到我们用h2桢完整表达了HTTP/1.x。但是h2协议抱负远不止于此。它的真正目的是解决之前HTTP1.x的线头阻塞问题、改善网络延迟和页面加载时间。我们知道一个完整的网页包含了主页请求和数次或数十次的子请求。HTTP/1.1已经可以并行发出所有请求.但是HTTP本身是无状态的协议，它依赖于时间的顺序来识别请求和响应直接的对应关系。先来的请求必须先给响应。那么如果后面的响应资源对浏览器构建DOM或者CSSOM更重要。那它必须阻塞等待前者完成。当然这也难不倒我们，我们可以多开几条tcp连接（浏览器规定一个origin(协议+host+port）最多6个）或者合并资源来减少不必要的阻塞。这是有代价的。首先tcp建连的开销，其实合并资源带来一小块子资源过期导致整个合并资源的缓存过期。对此，h2有一揽子的解决方案，接下来一一道来。h2在一个tcp连接创建多个流。每个流可以有从属关系，比如说根据浏览器加载的优先级顺序（主请求>CSS>能改变DOM结构的JS文件>图片和字体资源文件）建立一条依赖关系链。处于同一等级的依赖关系中可以设置权重。权重用于分配传输信道资源多少。图6例子说明了有一次主页请求index.html、一次main.css，一次jq.js以及一些image文件和字体文件qq.tff图3、h2请求的依赖树HTML的优先级最高，在HTML传输完成之前，其他文件不会被传输。HTML传输完成后，JS和CSS根据其分配的权重占比分配信息传输资源。如果CSS传输完成后，TFF和PNG如果是相同权重，那么他们将占有1/4的信道资源。这里抛出3个问题和答案。如果CSS被阻塞了,那么 JS 得到本属于CSS的通信资源如果CSS传输完成但没有被移依赖树, TFF和PNG继承CSS的通信份额 (假设TFF和PNG权重一样，那么各分得1/4通信资源).如果CSS在依赖数被移除，JS, TFF, PNG平分通信资源（假设3个权重一样，那么三者各分得1/3通信资源）第四话、众星捧月HTTP2还设计了一系列方案来改善网络的性能、包括流量控制，HPack压缩，Server Push。什么你说TCP已经有流量控制了，HTTP不是多此一举吗？没错，但是在单条TCP内部，各个流可是没有流量控制。流量控制使用了Update Frame不断告知发送方更新发送的窗口大小（上限）。流量控制一个现实用途是阻塞不重要的请求，以腾出更大的通信资源给重要的请求使用。流量控制是不可以被关闭的，流量大小可以设置2的31次方-1（2GB）。不同的中间网络设备有不一样的吞吐能力。流控的另一个用途在于同步所有的中间设备交换机最小的上限。流量窗口初始大小为65535（2的16次方-1）。就像世界上的大多数财富聚集在少数人身上一样。在一份对48,452,989个请求的统计中，以下11个头占据了99%的数量，依名次递减分别是user-agent、accetp-encoding、accept-language、accept、referer、host、connection、cookie、origin、upgrade-inseure-request、content-type。http header的值也有很大相似性，比如说”/index.html“, “gzip, deflate”。Cookie也携带冗余的信息。这些都组成了http header大量可以压缩的内容。而在一份GET请求和一个304响应或者content-length很少的响应中，这些头占据了很大比例的通信资源。2016年发布的一份HTTP报告中，请求头大约在460bytes，对一个通常的网页，平均会有140个请求对象。这些头总共需要63KB。这些量很有可能会是首屏和页面加载时间优化的瓶颈。可能你会说用gzip等压缩算法这些请求头，不就完了吗？的确spdy就这样干过，直到2013年BREACH攻击暴露了gzip压缩在https应用的安全性，这种攻击让攻击者很容易获得session cookie等数据。于是才有了HPACK。HPACK简单来说就是索引表，包括静态表和动态表。静态表由RFC定义，从不改变，静态表预留了62个表项。每个连接的通信双方维护着动态表。H2协议使用索引号代表http中的name、value或者name-value。假设被索引的是name，value没有索引，那么value还可以用霍夫曼编码压缩。在预定的头字段静态映射表 中已经有预定义的 Header Name 和 Header Value值，这时候的二进制数据格式如图4， 第一位固定为1， 后面7位为映射的索引值。图8的83就是这样的，83的二进制字节标示1000 0011，抹掉首位就是 3 ， 对应的静态映射表中的method：POST。图4、index索引name和value图5、抓包示意预定的头字段静态映射表中有 name，需要设置新值。图6所示例子，一个指定 path的Header，首字符 为 44 ，对应的二进制位0100 0100。前两个字符为 01 ，Index 为 4 ，即对应静态映射表中的 path 头。第二个字符为 95对应的二进制位 1001 0101，排除首字符对应的 Value Length 为 十进制的21。即 算上 44，一共23个字符来记录这个信息。图6、index索引name和自定义value图7、抓包示意预定的头字段静态映射表中没有 name，需要设置新name和新值。40 的二进制是0100 0000，02 的二进制是0000 0010，后七位的十进制值是 2，86 的二进制是1000 0110，后7位的十进制值是6。图8、index索引自定义name和自定义value图9、抓包示意明确要求该请求头不做hpack的indexHTTP2.0还有个大杀器是Server Push，Server Push利用闲置的带宽资源可以向浏览器预推送页面展示的关键资源，Server push有效得降低了页面加载时间。具体详情参考笔者的另一篇文章https://cloud.tencent.com/dev…。第五话、庖丁解牛HTTP2相比HTTP1更适合计算机执行。但是其二进制特性不易于人脑理解。这一话我们专门来讲讲关于http2的调试工具。Chrome(qq浏览器)可以按住F12查看h2协议。图13所示为浏览器网络时序图，列出了具体协议名称。chrome还可以在地址栏敲入chrome://net-internals/#http2查看到h2协议细节，如图11所示。点击相应的host就可以看到h2协商过程，如图12所示。图10、浏览器的网络时序图chrome://net-internals/#http2图11、chrome调试h2图12、h2协商过程wireshark（需和chrome或firefox搭配使用）。设置环境变量SSLKEYLOGFILE=c:tempsslkeylog.log。然后在Wireshark->Preferences->Protocols->SSL配置key所在路径。图13、wireshark配置图14、wireshark抓h2包Nghttp2是一个完整的http2协议实现的组件。作者也参与过spdy实现。目前nghttp2库被很多知名软件作为h2协议实现库使用。另外nghttp2也自带了h2协议的分析工具。图18展示了在明文状态使用upgrade头升级到h2c。图19展示了在https基础上升级到h2。图15、明文状态使用upgrade头升级到h2c图16、展示了在https基础上升级到h2Curl的—http2选项（需要和nghttp2一起编译）图17、支持h2的curl客户端调试Github还有些实用的http2工具组件，诸如chrome-http2-log-parser、http2-push-manifest等组件，笔者后续会专门开篇文章介绍这些工具。对于移动端的调试，ios可以用charles proxy做代理，android需要开发者模式使用移动端的chrome，笔者在移动端使用较少，这里就不做展开。第六话、雕栏玉砌H2怎么部署呢，目前主流服务端像nginx、apache都已经支持http2，主流的客户端curl和各种浏览器（包括移动端safari和chrome-android）基本也支持http2。代理服务器如ATS、Varnish，Akamai、腾讯云等CDN服务也支持http2。那么怎么把一套网站部署到h2。或者说部署h2网站和之前h1网站有什么不一样？如果是自己的源站，那么请确保服务器支持TLS1.2已经RFC7540所要求的加密套件，h2需要保证支持alpn。你可以使用ssllabs等网站检查。对于h2服务器的要求是h2必须了解如何设置流的优先级，h2服务器需要支持server push。h2客户端需要尽量多的发送请求。如果你的网站是从http1.x迁移过来的，那么之前对于http1.x所做的优化可能无任何帮助甚至更差。合并小文件不在需要，因为额外的小文件请求在h2看来只是开销很少。并且如果大文件的局部更改使得整个大文件缓存失效。在http1.0时代使用多个域名来并发http连接，在http2也毫无必要，因为http2天生就是并发的。http1.x做的优化比如说图片资源文件不使用cookie来减少请求大小，http2的header压缩功能也减少了这种影响。即使不做这种优化也亦可。像合并css、小图片带来的增益在http2.0也是可忽略的。如果网页使用第三方网站组件，那么请尽可能减少使用第三方网站组件。第三方网站不能保证支持h2，所以它可能成为木桶理论的最大短板。谨慎使用2.0-1.x的部署方案，h2流转化成h1请求。因为这样无法发挥h2性能。图18、2.0-1.x的部署方案CDN代理服务器的h2支持，可以屏蔽h2强制走tls的代理服务器。如图19，代理可以在与各种协议客户端的网络环境下，切断和客户端的tls连接，和服务器新建连接。也可以作为load balancer，相当于HTTP2.0用户和HTTP2.x服务器直接通信。图19、带tls客户端功能的代理图20列举如果绕过proxy到达h2服务器。此时的proxy相当于tcp转发的load balance功能的设备。如果该proxy支持tls的alpn协议，那么它也可以选择HTTP代理功能，和h2服务器可以建立加密连接。如果即不支持alpn，也不支持tcp转发。那么proxy只能用upgrade升级成h2协议。图20、经过代理服务器的H2部署方案第七话、十全九美HTTP2.0是建立在TCP之上，所以TCP的所有缺点他都有，所以H2能发挥最大性能得益于调优的tcp协议栈。TCP的慢启动特性，决定h2一开始的并发流量不会太大，TCP以及SSL的握手连接也会拖慢h2的首包网络耗时。QUIC则完全地抛弃TCP，在UDP基础上实现了HTTP2的一系列特性。同时做了应用层的如TCP的可靠性保障。同时这些TLS1.3传输更快更简洁。这些都为HTTP2.0进化到HTTP3.0提供了一些思路。总结以上内容都来源于笔者的实践经验和理论总结。篇幅所限不能涵盖各个细节。具体可以继续参考RFC7540和RFC7541协议。问答没有“http | https”的网址怎么实现？相关阅读我是怎么一步步用go找出压测性能瓶颈HTTP/2之服务器推送(Server Push)最佳实践低于0.01%的极致Crash率是怎么做到的？ 【每日课程推荐】新加坡南洋理工大学博士，带你深度学习NLP技术 ...