HTTP 2.0的存在问题
对于HTTP 2.0草案，HTTP 2.0在往返时延（RTT）上仍是一个问题，尤其是在移动网络方面。所以谷歌正在测试另一项协议，即QUIC。QUIC在TCP到UDP的网络转换上更加流畅。导致RTT的因素有：信号传播延迟(光在光纤和铜介质导线中传播速度是不同的)、网络服务器端以及用户端路由器跨越的数量、路由器是否拥堵以及路由器自身容量等。这些都不是Web用户或服务器端可以控制的。与此同时，客户端和服务器端处理网页的方式也会导致RTT，任何需要数据包传送的信号，即便数据包丢失或出错，都会增加客户端往返时延。所以这需要进行误差校正以及“数据包校验”，QUIC建议使用UDP传输代替TCP以避免TCP头线屏蔽。
http协议的详细描述
HTTP的早期版本为HTTP/0.9，它适用于各种数据信息的简洁快速协议，但是其远不能满足日益发展各种应用的需要。但HTTP/0.9作为HTTP协议具有典型的无状态性：每个事务都是独立进行处理的，当一个事务开始就在客户与服务器之间建立一个连接，当事务结束时就释放这个连接。HTTP/0.9包含
Simple-Request&Simple-Responsed的报文结构。但是客户无法使用内容协商，所以服务器也无法返回实体的媒体类型。
1982年，Tim Berners-Lee提出了HTTP/1.0，在此后的不断丰富和发展中，HTTP/1.0成为最重要的面向事务的应用层协议。该协议对每一次请求/响应，建立并拆除一次连接。其特点是简单、易于管理，所以它符合了大家的需要，得到了广泛的应用。其缺点是仍会发生下列问题：对用户请求响应慢、网络拥塞严重、安全性等。
1997年形成的HTTP/1.1，也就是现在普遍使用的协议，在持续连接操作机制中实现流水方式，即客户端需要对同一服务器发出多个请求时，其实现在多数的网页都是有多部分组成（比如多张图片），可用流水线方式加快速度，流水机制就是指连续发出多个请求并等到这些请求发送完毕，再等待响应。这样就大大节省了单独请求对响应的等待时间，使我们得到更快速的浏览。
另外，HTTP/1.1服务器端处理请求时按照收到的顺序进行,这就保证了传输的正确性。当然，服务器端在发生连接中断时，会自动的重传请求，保证数据的完整性。
HTTP/1.1还提供了身份认证、状态管理和Cache缓存等机制。这里，我想特别提一下关于HTTP/1.1中的Cache缓存机制对HTTP/1.0的不足之处的改进，它严格全面，既可以减少时间延迟、又节省了带宽。HTTP/1.1采用了内容协商机制，选择最合适的用户的内容表现形式。
现在，很多地方都有用到的虚拟主机技术在HTTP/1.1中也可以实现。所谓的虚拟主机技术，就是同一主机地址实际对应多台主机。通俗的讲，当你同时在一个网站申请两个主页时，用协议分析仪可以发现其实这两个主页对应的是同一个IP地址。这样用多台完全相同的机器形成WWW服务器就可以提高处理的吞吐量。
传统的解决方案是改造域名服务器使其可以根据一定的算法将同一域名解释成不同的IP地址。分别对应虚拟主机的每台机器，其缺点是要求每台机器占用完全独立的IP地址，这与IP地址的缺乏是相矛盾的。
HTTP/1.1提供的解决方案在HTTP协议自身中加入了指定不同主机的功能，从而多台主机可以共享一个IP地址，既提高了性能又便于管理。
因为HTTP/1.1是Internet现行的标准协议，这里详细介绍其相关语法。
首先，HTTP/1.1格式可写为：
[img:8d94cc43ef]http://www.china-pub.com/computers/emook/0472/1.gif[/img:8d94cc43ef]
其中请求方法是请求一定的Web页面的程序或用于特定的URL。可选用下列几种：
GET： 请求指定的页面信息，并返回实体主体。
HEAD： 只请求页面的首部。
POST： 请求服务器接受所指定的文档作为对所标识的URI的新的从属实体。
PUT： 从客户端向服务器传送的数据取代指定的文档的内容。
DELETE： 请求服务器删除指定的页面。
OPTIONS： 允许客户端查看服务器的性能。
TRACE： 请求服务器在响应中的实体主体部分返回所得到的内容。
PATCH： 实体中包含一个表，表中说明与该URI所表示的原内容的区别。
MOVE： 请求服务器将指定的页面移至另一个网络地址。
COPY： 请求服务器将指定的页面拷贝至另一个网络地址。
LINK： 请求服务器建立链接关系。
UNLINK： 断开链接关系。
WRAPPED： 允许客户端发送经过封装的请求。
Extension-mothed：在不改动协议的前提下，可增加另外的方法。
比如：
GET /index.html HTTP/1.1
Accept: text/plain /*纯ASCII码文本文件*/
Accept: text/html /*HTML文本文件*/
User-Agent:Mozilla/4.5(WinNT)
说明浏览器使用Get方法请求文档/index.html。浏览器则只允许接收纯ASCII码文本文件和HTML文本文件，其使用的引擎是Mozilla/4.5（Netscape）。
当服务器响应时，其状态行的信息为HTTP的版本号，状态码，及解释状态码的简单说明。现将5类状态码详细列出：
① 客户方错误
100 继续
101 交换协议
② 成功
200 OK
201 已创建
202 接收
203 非认证信息
204 无内容
205 重置内容
206 部分内容
③ 重定向
300 多路选择
301 永久转移
302 暂时转移
303 参见其它
304 未修改（Not Modified）
305 使用代理
④ 客户方错误
400 错误请求（Bad Request）
401 未认证
402 需要付费
403 禁止（Forbidden）
404 未找到（Not Found）
405 方法不允许
406 不接受
407 需要代理认证
408 请求超时
409 冲突
410 失败
411 需要长度
412 条件失败
413 请求实体太大
414 请求URI太长
415 不支持媒体类型
⑤ 服务器错误
500 服务器内部错误
501 未实现（Not Implemented）
502 网关失败
504 网关超时
505 HTTP版本不支持
比如：（在《TELNET……》一文中用telnet登陆80端口,相同的方法用在HTTP/1.1中,会发现没有显示，下面补充说明之）
telnet www.fudan.edu.cn 80
HEAD / HTTP/1.1
host:www.fudan.edu.cn /*本行为输入内容*/
HTTP/1.1 501 Method Not Implemented
Date: Web, 01 Nov 2000 07:12:29 GMT /*当前的日期/时间*/
Server: Apache/1.3.12 (Unix) /*Web服务器信息*/
Allow: GET, HEAD, OPTION, TRACE /*支持的方法类型*/
Connection: close
Connect-Type: Text/html; charset=iso-8859-1/*连接的媒体类型*/
501 Method
Not Implemented
Method Not Implemented
head to /inde
x.html not supported.
Invalid method in request head / htp/1.1
Apache/1.3.12 Server at www.fudan.edu.cn Port 80
关于实体头部的内容还可以有：
Last Modified ：请求文档的最近修改时间。
Expires ：请求文档的过期时间。
Connect-length：文档数据的长度。
WWW-authenricate：通知客户端需要的认证信息。
Connect-encoding ：说明有无使用压缩技术。
Transfer-encoding ：说明采用的编码变换类型。
随着Internet的发展，下一代的HTTP协议HTTP-ng已经在酝酿之中，它将会提供更好的安全性、更快的速度，其改进要点为：模块化强、网络效率高、安全性更好、结构更简单。
TCP 详解
title: TCP 总结 date: 2018-03-25 09:40:24 tags: categories: -计算机网络 我们都知道 TCP 是位于传输层的协议，他还有一个兄弟就是 UDP ，他们两共同构成了传输层。显然他们之间有很大的区别要不然的话在传输层只需要一个就好了。 其中最重要的区别就是一个面向连接另外一个不是，这个区别就导致了他们是否能够保证稳定传输，显然不面向连接的 UDP 是没办法保证可靠传输的，他只能靠底层的网络层和链路层来保证。我们都知道网络层采用的是不可靠的 IP 协议。好吧，网络层也保证不了可靠传输，所以 UDP 保证可靠传输只能依靠链路层了。 而 TCP 就好说了他不仅仅有底层的链路层的支持，还有自己的面向链接服务来保证可靠传输。当然 TCP也不仅仅就是比 UDP 多了一个可靠传输，前面也说到了这只是他们之间一个重要的区别。其实他的三个重要特性就是它们之间的区别。 * 可靠传输 * 流量控制 * 拥塞控制 TCP 主要是 确认重传机制 数据校验 数据合理分片和排序 流量控制 拥塞控制 依靠来完成可靠传输的 , 下面详细介绍这几种保证可靠传输的方式。 确认重传，简单来说就是接收方收到报文以后给发送方一个 ACK 回复，说明自己已经收到了发送方发过来的数据。如果发送方等待了一个特定的时间还没有收到接收方的 ACK 他就认为数据包丢了，接收方没有收到就会重发这个数据包。 好的，上面的机制还是比较好理解的，但是我们会发现一个问题，那就是如果接收方已经收到了数据然后返回的 ACK 丢失，发送方就会误判导致重发。而此时接收方就会收到冗余的数据，但是接收方怎么能判定这个数据是冗余的还是新的数据呢？ 这就涉及到了 TCP 的另外一个机制就是采用序号和确认号，也就是每次发送数据的时候这个报文段里面包括了当前报文段的序号和对上面的报文的确认号，这样我们的接收方可以根据自己接受缓存中已经有的数据来确定是否接受到了重复的报文段。这时候如果出现上面所说的 ACK 丢失，导致接受重复的报文段时客户端丢弃这个冗余的报文段。 好现在我们大致了解了确认重传机制，但是还有些东西还没有弄清楚，也就是 TCP 真正的实现究竟是怎样的。 这就是我们要解决的第一个问题就是如何确认。这里涉及到两种确认方式，分别称为 累计确认（捎带确认） 和 单停等协议 。 用一张图来快速理解，就是每发送一次数据，就进行一次确认。等发送方收到了 ACK 才能进行下一次的发送。 一样的也是采用的 ACK 机制，但是注意一点的是，并非对于每一个报文段都进行确认，而仅仅对最后一个报文段确认，捎带的确认了上图中的 203 号及以前的报文。 总结：从上面可以看到累计确认的效率更加高，首先他的确认包少一些那么也就是在网络中出现的大部分是需要传输的数据，而不是一半的数据一半的 ACK ，然后我们在第二张图中可以看到我们是可以连续发送多个报文段的（究竟一次性能发多少这个取决于发送窗口，而发送窗口又是由接受窗口和拥塞窗口一起来决定的。），一次性发多个数据会提高网络的吞吐量以及效率这个可以证明，比较简单这里不再赘述！ 结论：显然怎么看都是后者比较有优势，TCP 的实现者自然也是采用的累计确认的方式！ 上文中的那个特定的时间就是超时时间，为什么有这个值呢? 其实在发送端发送的时候就为数据启动了一个定时器，这个定时器的初始值就是超时时间。 超时时间的计算其实有点麻烦，主要是我们很难确定一个确定的值，太长则进行了无意义的等待，太短就会导致冗余的包。TCP 的设计者们设计了一个计算超时时间的公式，这个公式概念比较多，有一点点麻烦，不过没关系我们一点点的来。 首先我们自己思考如何设计一个超时时间的计算公式，超时时间一般肯定是和数据的传输时间有关系的，他必然要大于数据的往返时间（数据在发送端接收端往返一趟所用的时间）。好，那么我们就从往返时间下手，可是又有一个问题就是往返时间并不是固定的我们有如何确定这个值呢？自然我们会想到我们可以取一小段时间的往返时间的平均值来代表这一时间点的往返时间，也就是微积分的思想！ 好了我们找到了往返时间（RTT），接下来的超时时间应该就是往返时间再加上一个数就能得到超时时间了。这个数也应该是动态的，我们就选定为往返时间的波动差值，也就是相邻两个往返时间的差。 下面给出我们所预估的超时时间（TimeOut）公式： 很好，看到这里其实你已经差不多理解了超时时间的计算方式了，只不过我们这个公式不够完善，但是思路是对的。我们这时候来看看 TCP 的实现者们采用的方式。 好的，这就是 TCP 实现的超时时间的方式，但是在实际的应用中并不是一直采用的这种方式。假如说我们现在网络状态非常的差，一直在丢包我们根本没必要这样计算，而是采用直接把原来的超时时间加倍作为新的超时时间。 总结：好的现在我们知道了在两种情况下的超时时间的计算方式，正常的情况下我们采用的上面的比较复杂的计算公式，也就是 RTT+波动值 否则直接加倍 上面我们看到在发送方等待一个超时重传时间后会开始重传，但是我们计算的超时重传时间也不定就很准，也就是说我们经常干的一件事就会是等待，而且一般等的时间还挺长。那么可不可以优化一下呢？ 当然，在 TCP 实现中是做了优化的，也就是这里说到的快速重传机制。他的原理就是在发送方收到三个冗余的 ACK 的时候，就开始重传那个报文段。那么为什么是三个冗余的 ACK 呢？注意三个冗余的 ACK 其实是四个 ACK 。我们先了解一下发送 ACK 策略，这个是 RFC 5681 文档 规定的。 好的，那么现在我们可以看到如果出现了三个冗余的 ACK 他只可能是发生了两次情况三，也就是发送了两个比期望值大的数据。但是注意出现情况三有两种可能，一个是丢包，另外一个是乱序到达。 比如说我们现在是数据乱序到达的，我们来看一下。 第一种乱序情况 另外一种乱序 丢包情况 结论: 很显然我们可以看到，如果发生了乱序有可能会出现三次冗余 ACK，但是如果发现了丢包必然会有三次冗余 ACK 发生，只是 ACK 数量可能更多但是不会比三次少 在我们发现丢包以后我们需要重传，但是我们重传的方式也有两种方式可以选择分别是 GBN 和 SR 翻译过来就是 拉回重传 和 选择重传 。好其实我们已经能从名字上面看出来他们的作用方式了，拉回重传就是哪个地方没收到那么就从那个地方及以后的数据都重新传输，这个实现起来确实很简单，就是把发送窗口和接受窗口移回去，但是同样的我们发现这个方式不实用干了很多重复的事，效率低。 那么选择重传就是你想到的谁丢了，就传谁。不存在做无用功的情况。 结论: TCP 实际上使用的是两者的结合，称为选择确认，也就是允许 TCP 接收方有选择的确认失序的报文段，而不是累计确认最后一个正确接受的有序报文段。也就是跳过重传那些已经正确接受的乱序报文段。 数据校验，其实这个比较简单就是头部的一个校验，然后进行数据校验的时候计算一遍 checkSum 比对一下。 在 UDP 中，UDP 是直接把应用层的数据往对方的端口上 “扔” ，他基本没有任何的处理。所以说他发给网络层的数据如果大于1500字节,也就是大于MTU。这个时候发送方 IP 层就需要分片。把数据报分成若干片，使每一片都小于MTU.而接收方IP层则需要进行数据报的重组。这样就会多做许多事情,而更严重的是 ，由于UDP的特性,当某一片数据传送中丢失时 ， 接收方便无法重组数据报，将导致丢弃整个UDP数据报。 而在 TCP 中会按MTU合理分片，也就是在 TCP 中有一个概念叫做最大报文段长度（MSS）它规定了 TCP 的报文段的最大长度，注意这个不包括 TCP 的头，也就是他的典型值就是 1460 个字节（TCP 和 IP 的头各占用了 20 字节）。并且由于 TCP 是有序号和确认号的，接收方会缓存未按序到达的数据，根据序号重新排序报文段后再交给应用层。 流量控制一般指的就是在接收方接受报文段的时候，应用层的上层程序可能在忙于做一些其他的事情，没有时间处理缓存中的数据，如果发送方在发送的时候不控制它的速度很有可能导致接受缓存溢出，导致数据丢失。 相对的还有一种情况是由于两台主机之间的网络比较拥塞，如果发送方还是以一个比较快的速度发送的话就可能导致大量的丢包，这个时候也需要发送方降低发送的速度。 虽然看起来上面的两种情况都是由于可能导致数据丢失而让发送主机降低发送速度，但是一定要把这两种情况分开，因为前者是属于 流量控制 而后者是 拥塞控制 ，那将是我们后面需要讨论的事情。不要把这两个概念混了。 其实说到流量控制我们就不得不提一下滑动窗口协议，这个是流量控制的基础。由于 TCP 连接是一个全双工的也就是在发送的时候也是可以接受的，所以在发送端和接收端同时维持了发送窗口和接收窗口。这里为了方便讨论我们就按照单方向来讨论。 接收方维持一个接受窗口，发送方一个发送窗口。发送的时候要知道接受窗口还有多少空间，也就是发送的数据量不能超过接受窗口的大小，否则就溢出了。而当我们收到一个接收方的 ACK 的时候我们就可以移动接受窗口把那些已经确认的数据滑动到窗口之外，发送窗口同理把确认的移出去。这样一直维持两个窗口大小，当接收方不能在接受数据的时候就把自己的窗口大小调整为 0 发送窗口就不会发送数据了。但是有一个问题，这个时候当接收窗口再调大的时候他不会主动通知发送方，这里采用的是发送方主动询问。 还是画个图看的比较直观： 拥塞控制一般都是由于网络中的主机发送的数据太多导致的拥塞，一般拥塞的都是一些负载比较高的路由，这时候为了获得更好的数据传输稳定性，我们必须采用拥塞控制，当然也为了减轻路由的负载防止崩溃。 这里主要介绍两个拥塞控制的方法，一个是慢开始，另外一个称为快恢复。 那么问题来了，为什么需要序号呢？为什么又是三次握手而不是两次？以及什么是 SYN 洪泛攻击？ 这里需要说明一下的是最后的那个长长的 TIME_WAIT 状态一般是为了客户端能够发出 ACK 一般他的值是 1分钟 或者2分钟 好了，今天真的写了不少，主要就是把 TCP 的可靠传输以及连接管理讲清楚了，以及里面的一下细节问题，真的很花时间。然后其他没有涉及到的就是关于 TCP 的头并没有详细的去分析，这个东西其实也不是很难，但是现在篇幅真的已经很大就先这样，头里面的都是固定的不需要太多的理解。
TCP的含义
TCP的含义 TCP：传输控制协议 （TCP：Tran *** ission Control Protocol） 传输控制协议 TCP 是 TCP/IP 协议栈中的传输层协议，它通过序列确认以及包重发机制，提供可靠的资料流传送和到应用程式的虚拟连线服务。与 IP 协议相结合， TCP 组成了因特网协议的核心。 由于大多数网路应用程式都在同一台机器上执行，计算机上必须能够确保目的地机器上的软体程式能从源地址机器处获得资料包，以及源计算机能收到正确的回复。这是通过使用 TCP 的“埠号”完成的。网路 IP 地址和埠号结合成为唯一的标识 , 我们称之为“套接字”或“端点”。 TCP 在端点间建立连线或虚拟电路进行可靠通讯。 TCP 服务提供了资料流传输、可靠性、有效流控制、全双工操作和多路复用技术等。 关于流资料传输 ,TCP 交付一个由序列号定义的无结构的位元组流。 这个服务对应用程式有利，因为在送出到 TCP 之前应用程式不需要将资料划分成块， TCP 可以将位元组整合成栏位，然后传给 IP 进行传送。 TCP 通过面向连线的、端到端的可靠资料报传送来保证可靠性。 TCP 在位元组上加上一个递进的确认序列号来告诉接收者传送者期望收到的下一个位元组。如果在规定时间内，没有收到关于这个包的确认响应，重新发送此包。 TCP 的可靠机制允许装置处理丢失、延时、重复及读错的包。超时机制允许装置监测丢失包并请求重发。 TCP 提供了有效流控制。当向传送者返回确认响应时，接收 TCP 程序就会说明它能接收并保证快取不会发生溢位的最高序列号。 全双工操作： TCP 程序能够同时传送和接收包。 TCP 中的多路技术：大量同时发生的上层会话能在单个连线上时进行多路复用。 TCP\CP的含义 是 TCP是电脑网路的一种协议。 而TCCP则是手机通讯介面卡(Master板)和伺服器通讯的一种协议，该协议由国际电力行业标准的IEC104规约，规定采用Server／CLient通讯服务模式，采用Master板作伺服器，同是支援多客户登入。 用手机因为是移动的，所以会搜寻就近可用的伺服器。 搜寻到不同的，自动协议也不一样。 tcp/ip的含义是什么 TCP/IP协议叫做传输控制/网际协议，它是Inter国际网际网路络的基础。TCP/IP是网路中使用的基本的通讯协议。 虽然从名字上看TCP/IP包括两个协议，传输控制协议（TCP）和网际协议（IP），但TCP/IP实际上是一组协议，它包括上百个各种功能的协议，如：远端登入、档案传输和电子邮件等，而TCP协议和IP协议是保证资料完整传输的两个基本的重要协议。通常说TCP/IP是Inter协议族，而不单单是TCP和IP。 TCP/IP协议的基本传输单位是资料包（datagram）,TCP协议负责把资料分成若干个资料包，并给每个资料包加上包头（就像给一封信加上信封），包头上有相应的编号，以保证在资料接收端能将资料还原为原来的格式，IP协议在每个包头上再加上接收端主机地址，这样资料找到自己要去的地方，如果传输过程中出现数据丢失、资料失真等情况，TCP协议会自动要求资料重新传输，并重新组包。总之，IP协议保证资料的传输，TCP协议保证资料传输的质量。TCP/IP协议资料的传输基于TCP/IP协议的四层结构：应用层、传输层、网路层、介面层，资料在传输时每通过一层就要在资料上加个包头，其中的资料供接收端同一层协议使用，而在接收端，每经过一层要把用过的包头去掉，这样来保证传输资料的格式完全一致。 :baike.baidu./view/7729.htm 机器人焊枪TCP的含义？ 机器人TCP 是（TOOL CENTER POINT)，是指机器人安装的工具工作点。例如机器人焊枪的电极帽的工作位置等。 如何理解TCP/IP“对等实体”的含义 计算机网路系统是由各种各样的计算机和终端装置通过通讯线路连线起来的复杂系统。在这个系统中，由于计算机型别、通讯线路型别、连线方式、同步方式、通讯方式等的不同，给网路各结点的通讯带来诸多不便。要使不同的装置真正以协同方式进行通讯是十分复杂的。要解决这个问题，势必涉及通讯体系结构设计和各厂家共同遵守约定标准等问题，这也即计算机网路体系结构和协议问题。 1 协议的分层结构 两个系统间的通讯是一个十分复杂的过程，因此其相关协议的设计、实现和除错过程也是极其复杂的。为了减少这一过程的复杂性，通常网路协议都按结构化的层次方式来组织，功能根据相互间的依赖(呼叫)关系分别由各层完成。每一层都建立在它的下层之上。不同的网路，其层的数... casablanca的含义 casablanca [kæsə'blæŋkə] 卡萨布兰卡[摩洛哥西北部港市]即达尔贝达 可以做英文名阿 “帅”的含义？ 照照镜子就知道了 腻的含义 现代汉语词典 腻 nì ①食品中油脂过多，使人不想吃：油～│炖肉有点～│肥肉～人。 ②腻烦；厌烦：～得慌│他那些话我都听～了。 ③细致：细～。 ④黏：油搌布沾手很～◇～友。 ⑤污垢：尘～│垢～。 淦的含义 淦[gàn] 简明字义： 1.水入船中。2.河工称起伏很大的激浪。3.姓。 详细字义： 〈动〉 (1) (也作汵) (2) 水渗入船中 [water leak into ship] 淦,水入船中也。——《说文》。段玉裁注:“水入船中,必由朕(舟缝)而入。淦者,浸淫随理之意。” (3) 涂泥 [apply mud] 淦,泥也。——《说文》。段玉裁注:“谓涂泥也。” 〈名〉 (1) 河工术语。大溜;激溜 [torrent]。又河流中泓,由于河底坎坷不平,激溜成浪,起伏甚大者,在黄河下游,也称为淦 (2) 淦水,在江西省境 [Gan River]。源出清江县东南离山,北流经紫淦山入赣江 (3) 船舱中的水 [water in ship’s hold] “渊”的含义 渊 渊 yuān (会意。《说文》古文字形,外边大框象水潭,里面是打漩的水。本义:打漩涡的水) 同本义 [whirling water] 渊,回水也。——《说文》 水出地而不流,命曰渊水。,——《管子·度地》 鲵桓之审为渊,止水之审为渊,流水之审为渊。——《庄子·应帝王》 或跃在渊。——《易·干》 又如:渊环(回旋环绕);渊洑(水流汹涌起伏的样子) 深潭 [deep pool] 如临深渊。——《论语》。孔注:“潭也。” 鱼潜在渊。——《诗·小雅·鹤鸣》 不测不渊。——汉·贾谊《过秦论》 潜龙腾渊。——清·梁启超《饮冰室合集·文集》 又如:渊沦(潭中微波);渊涂(泥潭);渊潭(深潭);渊跃(龙在渊中跃动欲飞) 人或物聚集的处所 [haunt] 略茺裔之地,不如保殖五谷之渊。——《后汉书》 又如:渊府(指财物或文书等集聚的地方) 渊 渊 yuān 深;深远;渊博 [deep;profound] 渊,深也。——《小尔雅》 其心塞渊。——《诗·邶风·燕燕》 渊渊其渊。——《礼记·中庸》 又如:渊微(渊博细致、见微知著);渊才(渊博的才能);渊匠(学识,渊博的人);渊衷(内心);渊心(渊深的内心);渊玄(深邃;深奥);渊奥(深奥) 渊博 yuānbó [be broad and profound;erudite] 精深而广博 学识渊博 渊海 yuānhǎi [profound] 深渊和大海,比喻幽深而又广阔 渊默 yuānmò [elegant and upright]∶深沉、不说话 尸居而龙见,渊默而雷声。——《庄子·在宥》 [besilent]∶沉默不言 齐(斋)明盛服,渊默而不言。——《淮南子·秦族训》 渊深 yuānshēn [profound] 知识、计谋渊博,广泛而又精深 高帝明并日月,谋臣渊深。——《三国演义》 渊薮 yuānsǒu [gathering place of fish or beasts] 渊:深水,鱼住的地方;薮:水边的草地,兽住的地方。比喻人或事物集中的地方 为天下逋逃主萃渊薮。——《书·武成》 宛为大都,士之渊薮。——《后汉书·梁冀传》 婢子向闻天朝为人文渊薮,人才之广,自古皆然。——《镜花缘》 渊源 yuānyuán [source;origin] 源流,本原 测其渊源,览其清浊,未有厉俗独行若宁者也。——《三国志·管宁传》 事物渊源 渊 （渊） yuān ㄩㄢˉ 深水，潭：～水。～谷。～林。～薮（“渊”，鱼所聚处；“薮”，水边草地，兽所聚处；喻人或事物聚集的地方）。深～。临～羡鱼（喻只作空想，不作实际工作）。 深：～博。～源。～浩。～玄。～邈。～儒。～识（精深的见识）。
HTTP2和HTTPS来不来了解一下？
HTTP博文回顾： 本文 力求简单讲清每个知识点 ，希望大家看完能有所收获 最近在看博客的时候，发现有的面试题已经考HTTP/2了，于是我就顺着去了解一下。 到现在为止，HTTP协议已经有三个版本了： 下面就简单聊聊他们三者的区别，以及整理一些必要的额外知识点。 HTTP1.0和HTTP1.1最主要的区别就是： 在HTTP1.0默认是短连接： 简单来说就是： 每次与服务器交互，都需要新开一个连接 ！ 试想一下：请求一张图片，新开一个连接，请求一个CSS文件，新开一个连接，请求一个JS文件，新开一个连接。HTTP协议是基于TCP的，TCP每次都要经过 三次握手，四次挥手，慢启动 ...这都需要去消耗我们非常多的资源的！ 在HTTP1.1中默认就使用持久化连接来解决： 建立一次连接，多次请求均由这个连接完成 ！(如果阻塞了，还是会开新的TCP连接的) 相对于持久化连接还有另外比较重要的改动： 参考资料： 在说HTTP2之前，不如先直观比较一下HTTP2和HTTP1.1的区别： 上面也已经说了，HTTP 1.1提出了管线化(pipelining)理论，但是仅仅是限于理论的阶段上，这个功能默认还是关闭了的。 管线化(pipelining)和非管线化的 区别 ： HTTP2与HTTP1.1最重要的区别就是 解决了线头阻塞的 问题！其中最重要的改动是： 多路复用 (Multiplexing) 使用了HTTP2可能是这样子的： HTTP2所有性能增强的核心在于 新的二进制分帧层 (不再以文本格式来传输了)，它定义了如何封装http消息并在客户端与服务器之间传输。 看上去协议的格式和HTTP1.x完全不同了， 实际上HTTP2并没有改变HTTP1.x的语义 ，只是把原来HTTP1.x的header和body部分用 frame重新封装了一层 而已 HTTP2连接上 传输的每个帧都关联到一个“流” 。流是一个独立的，双向的帧序列可以通过一个HTTP2的连接在服务端与客户端之间不断的交换数据。 实际上运输时： HTTP2还有一些比较重要的改动： HTTP1.1新改动： HTTP2新改动： 参考资料： 之前在面试的时候被问到了HTTPS，SSL这样的知识点，也没答上来，这里也简单整理一下。 首先还是来解释一下基础的东东： 3y的通讯之路： 对于数字签名和CA认证还是不太了解参考一下 回到我们的HTTPS，HTTPS其实就是在HTTP协议下多加了一层SSL协议(ps:现在都用TLS协议了) HTTPS采用的是 混合方式加密 ： 过程是这样子的： 所以相比HTTP，HTTPS 传输更加安全 参考资料： 我只是在学习的过程中，把自己遇到的问题写出来，整理出来，希望可以对大家有帮助。如果文章有错的地方，希望大家可以在评论区指正，一起学习交流~ 参考资料： 文章的目录导航 ：
