Http

HTTP状态码（HTTP Status Code）是用以示意网页服务器超文本传输协定响应状态的数字代码。这些状态码由RFC 2616标准定义，并失去其余多个标准的扩大。 HTTP 状态码是由三位数字组成的，它们被分为五个不同的类别，每个类别有特定的含意。状态码的第一个数字代表了响应的五种状态之一，包含信息性状态码、胜利状态码、重定向状态码、客户端谬误状态码和服务器谬误状态码： 1xx - 信息响应：这些状态码示意长期的响应，期待客户端持续操作 2xx - 胜利：这类状态码示意客户端的申请被胜利接管、了解和承受 3xx - 重定向：客户端须要采取进一步的操作能力实现申请 4xx - 客户端谬误：这类状态码示意客户端仿佛有谬误，例如，申请信息有误或申请无奈执 5xx - 服务器谬误：这类状态码示意服务器在尝试解决申请时外部出错或者无奈实现申请 每种类别蕴含许多的状态码，德迅云平安就简略分享一些咱们比拟常遇到的一些状态码： 401 Unauthorized 未受权。这示意申请须要身份验证。通常，这意味着申请须要蕴含无效的用户名和明码或其余身份验证凭据能力持续。这个状态码的要害有： 1、当服务器返回 401 状态码时，它通常会在响应头中蕴含一个 WWW-Authenticate 字段，这个字段通知客户端应该如何进行认证。例如，它可能批示客户端应用根本认证（Basic Authentication）或摘要认证（Digest Authentication）等形式。2、当客户端收到 401 状态码时，它通常会提醒用户输出认证信息（如用户名和明码）。而后，客户端会应用这些信息从新发送申请，通常在申请头中蕴含认证信息。3、尽管 401 和 403 状态码都示意客户端的申请被回绝了，但起因不同。401 示意客户端须要进行认证能力拜访资源，而 403 示意即便客户端进行了认证，也因为某些起因（如权限有余）而不能拜访资源。 403 Forbidden 禁止拜访。服务器收到申请，然而回绝提供服务。这可能是因为权限问题或其余起因导致的。须要查看服务器的权限设置，确保申请的用户有拜访资源的权限。这个状态码的要害有：1、当服务器返回 403 状态码时，它示意客户端的申请被服务器拒绝执行。这通常意味着客户端没有权限拜访所申请的资源。2、有时候，403 谬误可能是因为服务器配置谬误导致的。例如，服务器上某些文件或目录的权限设置可能不容许某些用户或客户端拜访。3、与 401 Unauthorized 状态码不同，403 Forbidden 示意客户端曾经通过了身份验证（如果有的话），但依然没有权限拜访所申请的资源。而 401 示意客户端须要进行身份验证能力拜访资源。4、当客户端收到 403 状态码时，它通常会显示一个谬误音讯，通知用户他们无法访问所申请的资源。客户端通常不会提醒用户从新输出认证信息，因为问题可能与权限而不是认证无关。 404 Not Found HTTP状态码 "404 Not Found" 大家最相熟不过了，这个状态码用来示意服务器无奈找到客户端申请的资源。这意味着客户端可能与服务器胜利通信，但服务器未能找到申请的特定页面或文件。就像你在手机上点了一份外卖。你等着外卖员送来你的食物，然而外卖员却找不到你提供的地址，以下是对于 "404 Not Found" 的一些关键点： 1.资源不存在：这个状态码通常示意申请的URL对应的资源（如网页、图片、文件等）在服务器上不存在。这可能是因为资源已被删除、挪动或从未存在。（就像你要求的特定餐厅或菜品在外卖平台上曾经不再提供，就像某个网页或资源被网站移除） ...

首先须要先理解什么是http和https。http全称是超文本传输协定、https全称是平安超文本传输协定，仅仅两字之差区别却十分大，其之间的次要区别在于数据传输的安全性和完整性。上面在几个方面带大家更直观的理解：1、身份信息认证方面：http是不反对服务器身份验证的，任何网站都能够假冒非法网站。https是应用了受信赖的证书颁发机构（CA）签发的SSL/TLS证书，可能验证服务器身份、避免钓鱼攻打和域名假冒，为用户提供网站的真实性和安全性的保障。注（R3证书则是不验证服务器身份的SSL证书，所以会存在相当一部分不法网站应用该证书，导致该证书兼容性方面的欠缺） 2、连贯形式方面：http是一种无状态且无加密的文本数据传输协定，其连贯简略且无奈短暂。https则是基于SSL/TLS握手协定建设连贯，该过程波及到身份验证、协商加密算法和替换会话密钥等（过程会存在公钥和私钥的交互），确保服务器端和浏览端的平安信息替换。 3、端口方面：http是默认应用80端口通信的。https则是默认应用443端口通信。 4、平安性能方面：http是明文传输，不提供任何模式的数据加密，所有的客户端与服务器之间的数据传输的信息都是可见的，包含用户凭证、cookie和其余隐衷信息。这使得http非常容易受到中间人攻打。https是通过SSL/TLS协定对传输数据进行加密，确保了数据的隐衷性。即使有第三方获取了加密数据也很难进行读取和篡改信息。 5、性能老本http因为没有加密环节，因而在等同环境下传输速度绝对会更快一些，资源耗费也会少一些。https因为波及到了加密操作，有可能会使得加载速度变慢一些，然而影响不大，目前服务器和浏览器的优化措施做的还是很好的。同时在购买和部署SSL/TLS证书时会产生肯定的费用。 目前领有根底性能的SSL/TLS证书的价格也并不贵，在有条件的状况下能够间接在受信赖的证书颁发机构JoySSL进行征询，能够先向JoySSL官网工作人员发送本人须要爱护的域名，提交本人所须要的证书类型，注册时填写230912即可获取优惠。 配合操作域名解析申请，不会操作的话也会有工作人员帮助装置部署。 装置好证书后即可实现https

SSL（Secure Sockets Layer）证书是保障网站平安、确保用户数据加密传输的要害元素。当SSL证书靠近其有效期限时，及时更换新证书至关重要，免得影响网站的安全性和用户体验。上面是一份详尽的指南，领导您分步有序地实现SSL证书更换的过程。 第一步：查看现有证书的有效期首先，登录您的服务器或网站控制面板，查看以后SSL证书的有效期限。大多数状况下，证书详情中会明确标注出证书的到期日期。另外，一些出名的SSL证书颁发机构（Certificate Authorities, CAs）会提供证书治理服务，主动发送过期预警告诉，确保您提前做好筹备。 第二步：抉择并购买新证书续订证书：若称心现有证书的类型（如DV、OV或EV），能够抉择向同一证书颁发机构续订原有的SSL证书。购买新证书：依据网站的具体需要，评估是否须要降级证书类型（如从单域名证书降级到多域名或通配符证书）。比照各大CA的价格、服务和反对，抉择最适宜您的SSL证书，并实现购买流程。收费SSL证书：证书详情 第三步：生成新的证书签名申请（CSR）CSR蕴含了您网站的根本信息和公钥，它是获取SSL证书的前提条件。在服务器或托管服务商提供的工具中，依据批示生成新的CSR，确保信息准确无误。第四步：提交CSR并验证身份将生成的CSR提交给证书颁发机构。依据不同类型的证书，CA可能会要求您进行相应的验证过程，如域名所有权验证（DV）、组织验证（OV）或扩大验证（EV）。第五步：接管并装置新的SSL证书在CA实现验证并通过后，他们会将新的SSL证书文件发给您。收到证书文件后，请将其下载并保留在平安的中央。在您的服务器环境中，找到原证书所在位置并备份旧证书。而后，替换掉旧证书文件，将新证书文件及其对应的私钥和两头证书（如果有的话）别离搁置在正确的目录下。对于Web服务器软件（如Apache、Nginx、IIS等），须要更新配置文件以指向新的SSL证书门路，并重启服务器以利用更改。第六步：测试与确认更换证书后，立刻通过浏览器拜访您的网站，确认URL已显示为“https”结尾，并显示平安锁标记，示意新证书已胜利装置并失效。应用SSL检测工具（如Qualys SSL Labs）进行全面的SSL配置查看，确保所有设置均合乎平安标准。收费SSL证书：证书详情 更换行将过期的SSL证书是一项必要的惯例保护工作，遵循上述步骤不仅能确保网站不间断的平安服务，还能防止因证书过期引发的用户体验降落和搜索引擎排名稳定等问题。定期监控证书状态并与牢靠的SSL证书颁发机构单干，是放弃网站平安的最佳实际之一。

在寰球范畴内，Sectigo作为一家备受信赖的数字证书颁发机构，以其弱小的安全性、杰出的性价比和卓越的品牌形象博得了宽广用户的青眼。本文将深刻分析Sectigo SSL证书在这些方面的卓越体现。 一、安全性1. 弱小加密技术Sectigo SSL证书采纳行业标准的加密技术，反对高达256位的SSL/TLS加密，确保在线交易、登录信息和其余敏感数据在传输过程中失去充沛爱护，无效避免中间人攻打和数据泄露危险。 2. 多层次验证Sectigo提供多种验证级别的SSL证书，从只需验证域名所有权的DV（域名验证）证书，到严格审查企业实在身份的OV（组织验证）和EV（扩大验证）证书。尤其是EV证书，能在浏览器地址栏显示绿色公司名称，为访问者提供最直观的平安提醒。 3. 惯例更新与兼容性Sectigo始终保持与最新平安规范和技术的同步，其SSL证书与所有支流浏览器和操作系统具备良好的兼容性，并定期自动更新，保障网站继续享受最高等级的平安防护。 二、性价比1. 灵便的产品线Sectigo SSL证书产品线丰盛，笼罩单域名、多域名、通配符等多种类型，满足不同规模和类型网站的需要。无论用户是集体博主还是大型企业，都能在Sectigo找到合乎估算和性能需要的现实计划。 2. 综合老本效益Sectigo SSL证书以正当的定价策略在市场上享有竞争劣势，同时提供长期订阅折扣和批量购买优惠，使得用户在确保网站平安的同时，无需承当过高的财务压力。此外，其一站式的证书治理平台升高了保护老本，进一步晋升了整体性价比。 三、品牌形象1. 行业领导位置Sectigo作为寰球当先的SSL证书提供商，其品牌影响力不容小觑。与Sectigo单干，意味着您的网站与业界权威建立联系，从而加强访问者的信任度和忠诚度。 2. 可见的信赖标识特地是Sectigo的EV SSL证书，可能在浏览器地址栏中出现醒目的绿色公司名称，这不仅是对网站安全性的强有力证实，更是晋升品牌形象和信用的要害工具。 3. 客户服务与反对Sectigo致力于提供优质的客户服务和技术支持，凭借其业余团队，用户在选购、装置和治理SSL证书的过程中，都能享受到高效、及时的帮忙，这也间接地进步了品牌的市场竞争力和客户满意度。 填写注册码 230907 优惠申请SSL证书：Sectigo证书详情 综上所述，无论是从严格的平安保障、经济实用的性价比，还是显著晋升品牌形象的角度来看，Sectigo SSL证书都是各类网站建设和运营者的现实之选。抉择Sectigo，即是抉择了业余的平安保障与值得信赖的品牌承诺。

前言本教程将向您介绍如何应用 Amazon Lightsail 服务的收费套餐轻松搭建属于您的远程桌面。依靠于 Amazon 寰球可用区，您能够在世界各地搭建合乎您配置需要的远程桌面。 本教程须要先领有亚马逊云科技海内账户。当初注册亚马逊云科技账户能够享受12个月收费套餐，包含 EC2 等多种热门产品。 亚马逊云科技开发者社区为开发者们提供寰球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、流动与比赛等。帮忙中国开发者对接世界最前沿技术，观点，和我的项目，并将中国优良开发者或技术举荐给寰球云社区。如果你还没有关注/珍藏，看到这里请肯定不要匆匆划过，点这里让它成为你的技术宝库！教程阐明进入开发环境 点击右侧按钮“登陆控制台”进入开发环境，如果您还没有账户，请先注册账户。 海内区域业务或集体应用，请注册“海内区域账户”； 中国区域业务（需企业营业执照认证），请注册“中国区域账户”。 第一步 - 启动 Amazon Lightsail 实例从所有服务中的 （Compute）计算下找到 Lightsail，点击关上 Lightsail 控制面板。 进入 Amazon Lightsail 欢送界面之后，单击 Create instance（启动实例）来创立和配置 Lightsail 实例。您也能够在右下角语言选项中抉择中文，不便设置。 第二步 - 配置远程桌面在弹出的设置界面，自上而下，能够抉择： 虚构桌面的 IP 地位；操作系统平台（这里举荐初学者抉择 Windows，方便管理, 虚构桌面零碎版本没有特殊要求就抉择最新版 windows 即可）;配置和付费打算（目前收费试用的配置都能够体验3个月)；抉择好当前，点击创立实例。 实例状态为“待处理”示意正在为您创立 Lightsail 实例。 第三步 - 启动远程桌面稍等片刻，实例显示“正在运行”则示意曾经配置实现。并且右上角会有1个显示器的图标。 点击显示器图标后，会弹出虚构桌面窗口。 第四步 - 应用远程桌面能够调用虚构键盘输入 也能够应用右下角的近程剪切板性能输出字符，而后复制并粘贴到远程桌面中。 用虚构桌面中的浏览器能够查问以后远程桌面的 IP 地址。 文章起源：https://dev.amazoncloud.cn/column/article/650a981127bafa5d376...

在某些状况下，您可能须要在电脑上设置HTTP代理以拜访特定的网络资源或爱护您的隐衷。本文将为您提供具体的步骤，教您如何在电脑上设置HTTP代理。 电脑怎么设置http代理，具体配置办法介绍 以下是在Windows和Mac电脑上设置HTTP代理的步骤： 在Windows上设置HTTP代理： 1. 关上控制面板：点击Windows开始菜单，搜寻并关上“控制面板”。 进入Internet选项：在控制面板中，找到并点击“网络和Internet”选项，而后点击“Internet选项”。关上连贯选项卡：在Internet选项窗口中，点击顶部的“连贯”选项卡。配置代理设置：在连贯选项卡中，找到“局域网设置”局部，并点击“局域网设置”按钮。设置HTTP代理：在局域网设置窗口中，勾选“应用代理服务器”复选框，并输出代理服务器的IP地址和端口号。保留设置：实现代理配置后，点击“确定”按钮保留更改。在Mac上设置HTTP代理： 1. 进入网络偏好设置：点击屏幕右上角的苹果图标，抉择“零碎偏好设置”，而后点击“网络”。 抉择网络连接：在网络窗口中，抉择您以后应用的网络连接，如Wi-Fi或以太网。配置代理设置：在右侧的设置选项中，点击“高级”按钮，而后抉择“代理”选项卡。设置HTTP代理：在代理选项卡中，勾选“Web代理(HTTP)”复选框，并输出代理服务器的IP地址和端口号。保留设置：实现代理配置后，点击“确定”按钮保留更改。设置实现后，您的电脑将开始应用配置的HTTP代理。请留神，不同的应用程序可能有本人的代理设置选项，您可能须要在特定应用程序中独自配置代理设置。 在设置HTTP代理时，请确保您取得了正确的代理服务器信息，包含IP地址、端口号和任何身份验证凭据（如果须要）。这些信息通常由您的网络管理员或代理服务提供商提供。 心愿本文提供的电脑上设置HTTP代理的指南对您有所帮忙。通过配置和应用流冠HTTP代理，您能够管制电脑上的网络流量并实现更平安和私密的网络浏览体验。

在工作中，往往会须要将文件同时共享给很多台电脑。本篇介绍HHDESK的HTTP文件服务性能，通过浏览器，将本地资源共享给任意主机。 1 共享文件首页——资源管理——服务端——“+”，在弹出框中抉择HTTP文件服务。填写各项内容。 留神端口号、用户名和明码，接下来须要用到。 备注：共享者能够右键连贯——信息，进行查看和操作。 并且能够随时断开链接 2 接管文件须要文件的用户，只需在本人电脑上关上浏览器，输出地址，地址为“IP+端口号”；弹出框中填入方才设置的用户名和明码。 点击登陆，即可关上共享文件夹。 能够对文件进行操作。

还是用一下上一篇文章画的图 TCP 的 11 个状态，每一个状态都缺一不可，天然 TIME_WAIT 状态被赋予的意义也是相当重要，咱们间接论断后行 上文咱们提到 tcp 中，被动敞开的一边会进入 TIME_WAIT 状态， 另外 Tcp 中的有 TIME_WAIT 状态，次要是有如下 2 个起因： 为了避免被动敞开一方的提早数据被其余连贯窃取<!----> 为了避免被动敞开的一方，没有收到最初的一个 ACK 包如何了解呢？ 为了避免被动敞开一方的提早数据被其余连贯窃取对于第一个 咱们一个一个的来具体解释一下，还是下面这个图，咱们人为的加一点异样的状况 咱们在 tcp 连贯中，客户端先发动敞开，那么 TIME_WAIT 状态就在客户端这边，如下： 这是一个失常的客户端和服务端通信的根本过程，那么，如果在 client 和 server 建设连贯后，server 端向 client 端发发送的数据，在网络环境中有提早，短时间，没有顺利的达到 client 端的时候，就会呈现如下状况 如上图 咱们人为的画了一个会呈现在事实工作中的问题，当 client 和 server 失常连贯，server 给 client 发的 seq=100 的包，因为网络拥挤等起因，留在了网络环境中<!----> client 首先发动敞开连贯，如果这个时候，没有 TIME_WAIT 状态，或者咱们人为的将 TIME_WAIT 的值设小，就会呈现 seq=100 这个包不能失常的被 client 收到，因为 client 曾经是 CLOSED 状态了<!----> ...

一、HTTP协定的简介HTTP协定是一种数据通信协定，是浏览器与服务器之间的协定，HTTP协定的中文全称为超文本传输协定，HTTP协定在直播程式源码平台中，承载着数据传输的重要工作，用户能够通过HTTP协定获取直播程式源码平台中提供给用户的信息与视频资源，并通过网络流传输到用户端。 二、直播程式源码平台HTTP协定的作用资源数据获取传输：HTTP协定作为一个在浏览器与客户端之间进行传输的协定，能够使直播程式源码平台经营URL来获取和发送用户的数据和各种资源，比方用户上传的图片、音视频等或是直播程式源码平台本身的直播流、CSS样式表等，对直播程式源码平台有着重要作用。建设客户端与用户端的通信连贯：用户能失常应用直播程式源码平台，就须要用户在应用直播程式源码平台进行操作时，客户端可能响应是重要条件之一，HTTP协定就能够建设客户端与用户端的通信连贯，当用户应用直播程式源码平台或在直播程式源码平台进行操作时，HTTP协定就会发送给服务器HTTP申请，之后将相应数据再返回到客户端，实现互动与数据交换。缓存和代理反对：HTTP协定反对缓存机制，使得服务器能够将在直播程式源码平台中用户一些常常申请的资源保留在缓存中，在下次申请时能够间接返回缓存的数据，从而缩小直播程式源码平台带宽占用并进步响应速度。HTTP协定还反对代理服务器，能够在直播程式源码平台的客户端和服务器之间进行直达，进一步优化网络传输。三、HTTP协定在直播程式源码平台的多种搭建形式应用Nginx作为HTTP代理服务器：Nginx是一个风行的HTTP代理服务器，能够在服务器上安装Nginx，并将直播平台的动态资源（例如图片、视频、脚本等）寄存到Nginx的代理目录中。用户在浏览器中输出直播平台的URL时，Nginx会将申请转发到服务器上，并将响应返回给浏览器。应用Apache HTTP服务器：Apache是一个风行的HTTP服务器，能够在服务器上安装Apache，并将直播平台的动态资源寄存到Apache的文档根目录中。用户在浏览器中输出直播平台的URL时，Apache会将申请转发到服务器上，并将响应返回给浏览器。四、论断在直播程式源码平台中，HTTP协定扮演着数据传输的重要角色，HTTP协定可能让直播程式源码平台获取和发送数据、让用户的操作可能建设客户端与用户端的通信连贯与缓存和代理反对，这些都能让用户在直播程式源码平台取得稳固、晦涩的直播体验，满足用户对高质量内容的需要，是直播程式源码平台不可或缺的优质协定之一。

502，504在超时场景下很容易被混同，辨别起来有肯定难度；499 产生的起因往往也会和 504 会有外在关联。注：本文为间断测试，所以批改nginx或php-fpm配置后，记得重启 根本环境(LNMP)：nginx 配置fastcgi_connect_timeout 5; # nginx连贯fastcgi的超时工夫fastcgi_send_timeout 10; #nginx往fastcgi发送参数的超时工夫fastcgi_read_timeout 10; #nginx从fastcig获取数据的超时工夫php-fpm 配置request_terminate_timeout = 30 ; 一次申请的最长执行工夫PHP脚本：nginx的webroot创立codetest.php文件，通过拜访 localhost/codetest.php 复现http响应code；499 复现php-fpm.conf：request_terminate_timeout=30nginx：fastcgi_read_timeout 5;代码：sleep(15); echo 'hello world'; 499报错信息： Client Closed Request；即 客户端被动断开连接。指一次http申请在客户端指定的工夫内没有返回响应，此时，客户端会被动断开连接，此时表象为客户端无响应返回；此状态码在浏览器申请时简直不可见，因为浏览器默认超时工夫很长；多见于业务架构中的服务模块之间的调用。 复现路径:在linux终端应用curl命令申请，-m 示意超时工夫，单位秒curl -i -m 3 http://127.0.0.1/codetest.php返回：Operation timed out after 3004 milliseconds with 0 bytes received此时，nginx的 access_log 会呈现如下信息："HEAD /codetest.php HTTP/1.1" 499 502 复现502，Bad Gateway，网关谬误，它往往示意网关从上游服务器中接管到的响应是有效的。 先来理解一下网关是什么含意从宏观定义上来说只有是连贯两个不同网络设备的都能够叫网关，具体到Http申请这里，网关就是指是转发其余服务器通信数据的服务器，于本文而言，Nginx 就是网关。 502并不是指网关自身出了问题，而是从上游接管响应出了问题，比方因为上游服务本身超时导致不能产生响应数据，或者上游不依照协定约定来返回数据导致网关不能失常解析。 复现门路-1敞开php-fpm过程，返回502。这个比拟容易了解，参照下面的定义，因为php-fpm过程敞开，nginx连贯不上php-fpm，即nginx不能收从下层接管到响应数据。 nginx 谬误日志相似如下内容：connect() to unix:xxxx/php-cgi.sock failed (2: No such file or directory) while connecting to upstream ...

1 背景http申请是常见的一种网页协定，咱们看到的各种网页，其实都是发送了http申请失去了服务器的响应，从而将数据库中简单的数据以简略、直观的形式出现进去，不便公众浏览、应用。而如何发送http申请呢？明天来探讨一下应用requests模块，达到高效、简略的http申请操作。 2 什么是requestsrequests是用python语言基于urllib编写的，采纳的是Apache2 Licensed开源协定的HTTP库，尽管规范库中的urllib2模块曾经蕴含了平时咱们应用的大多数性能，然而urllib2的API应用起来并不太敌对，而requests自称“HTTP for Humans”，通过高度封装当前，能够间接调用此库的相干函数，十分不便帮忙咱们实现爬取HTML网页页面、模仿主动提交网络申请等操作。 []() requests模块始终在迭代更新，以齐全适应以后的所有网络申请。 []() 反对的 HTTP 个性： 放弃流动和连接池国际域名和 URLCookie 持久性会话浏览器式 SSL 验证主动内容解码根本 / 摘要身份验证优雅的键 / 值 Cookie主动减压Unicode 响应机构HTTP（S）代理反对分段文件上传流下载连贯超时分块申请.netrc 反对线程平安3 如何装置装置requests模块与装置其余python模块一样，应用pip命令装置即可。 pip install requests# 如需指定版本pip install requests==2.27.14 如何应用4.1 七个次要办法[]() 4.2 HTTP协定对资源的操作[]() 4.3 响应公共办法[]() 4.4 罕用形式举例4.4.1 requests.request()method：提交形式（get｜post）； url：提交地址； kwargs：14个管制拜访的参数； []() 罕用的参数有：params、data、json、headers、cookies，其余参数解说与示例将在（二）中进行介绍。 示例： params：在url上传递的参数，GET模式传递到后盾。import requestsrequests.request(method = 'GET', url = 'http://127.0.0.1:8080/example/request', # 字典data= { 'k1' : 'v1' , 'k2' : 'v2' , 'x':[1,2,3]} # 字符串data="k1=v1&k2=v2&x=[1,2,3]"# 字节data = bytes("k1=v1&k2=k2&x=[1,2,3]", encoding='utf8') )# http://www.oldboyyede.com?k1=v1&k2=v2data：在申请体外面传递的数据，前面能够是字典，字节等数据类型。import requestsrequests.request(method = 'POST',url = 'http://127.0.0.1:8080/example/request',# 字典data= { 'k1' : 'v1' , 'k2' : 'v2' , 'x':[1,2,3]} # 字符串data="k1=v1&k2=v2&x=[1,2,3]"# 字节data = bytes("k1=v1&k2=k2&x=[1,2,3]", encoding='utf8')# 文件对象data = open('data_file.py', mode='r', encoding='utf-8'))json：在申请体外面传递数据，把整体序列化成一个大字符串，字典中嵌套字典的话用JSON序列化。import requestsrequests.request(　method = 'POST',　url = 'http://127.0.0.1:8080/example/request',　json = {'k1' : 'v1', 'k2' : 'v2'} # "{ 'k1' : 'v1' , 'k2' : 'v2' }"# 字典嵌套字典json = json.dumps({'k1' : 'v1' , 'k2' : { 'kk1' : vv1 }}))headers：在申请体中增加申请头import requestsrequests.request(method='POST',url='http://127.0.0.1:8080/example/request',json={'k1': 'v1', 'k2': 'v2'},headers={'Content-Type': 'application/x-www-form-urlencoded'})cookies：在申请体中增加cookieimport requestsrequests.request(method='POST',url='http://127.0.0.1:8080/example/request',data={'k1': 'v1', 'k2': 'v2'},cookies={'cookie_example': 'cookie_value1'},)# 也能够应用CookieJar（字典模式就是在此基础上封装）from http.cookiejar import CookieJarfrom http.cookiejar import Cookieobj = CookieJar()# 构建cookieobj.set_cookie(Cookie(version=0, name='c1', value='v1', port=None, domain='', path='/', secure=False, expires=None,discard=True, comment=None, comment_url=None, rest={'HttpOnly': None}, rfc2109=False,port_specified=False, domain_specified=False, domain_initial_dot=False, path_specified=False))# 发送申请requests.request(method='POST',url='http://127.0.0.1:8080/example/request',data={'k1': 'v1', 'k2': 'v2'},cookies=obj)4.4.2 requests.get()结构一个向服务器申请资源的request对象，而后返回一个蕴含服务器资源的response对象。 ...

近两年，游戏出海曾经成为了出海热潮中的一员。在“后宅经济时代”的影响下，也得益于海内市场的互联网人口，游戏出海涨势十分迅猛。局部游戏在短时间内走红后，就会受到了一些“有心人”发动的歹意网络攻击，其中最为常见的一种就是 DDoS 攻打。 在聊 DDoS 攻打之前，咱们先来看看什么是 DoS。 DoS和DDoS当个别 IT 基础设施组件负载过高时，通常会产生拒绝服务的状况，咱们称之为 DoS（拒绝服务）。如果是这是因为攻击者用大量申请吞没指标链接，以致于服务器无奈再解决所有申请时，即为 DoS 攻打。DoS 攻打会造成设施、操作系统和单个服务器服务只能以提早的形式响应申请（如果还没齐全宕机的话）。DoS 的一种常见模式称为 “分布式拒绝服务” （DDoS，Distributed Denial of Service）。 以游戏 App 为例，DDoS 攻打的发起者不是只应用一台计算机，他们通过用大量不同机器的申请去 “轰炸” 这个游戏的服务器，最终导致服务器负载过重，运行的零碎就会变慢甚至齐全解体。这样，真正的游戏用户就无奈再高兴地游玩这个游戏。 举个具体的例子，让大家更分明地理解什么是 DDoS 攻打。二狗子开了一家有 50 个座位的火锅店，用料上成食材陈腐，生意特地红火，而隔壁老王家的火锅店却无人问津。隔壁老王为了凑合二狗子，叫了 50 集体去二狗子的店里坐着，找二狗子问这问那，然而他们就是不点菜，还占着座位赖着不走。二狗子和他的火锅店都解体了，因为真正的顾客进店连坐的中央都没有，也得不到激情的服务。 DDoS 攻打的根底根本是宏大的计算机群体。这些计算机攻打源组合在一起造成了微小的僵尸网络，这样微小的网络会产生比单个零碎执行的简略 DoS 攻打更多的流量。DDoS 攻打会对网站治理造成相当严重的影响，因为定位攻打源的心愿通常很渺茫。攻击者往往会向保护措施有余的计算机植入代码程序，即计算机病毒，这些计算机会在管理员不知情的状况下被攻击者管制。现在，路由器、监控摄像头或数字视频录像机等 IoT（物联网）设施应用也越来越频繁，这些设施也可能被利用变为 “僵尸主机”。 DDoS攻打类型与其余品种的网络入侵不同，DDoS 攻打不会去试图浸透零碎。相同，它可能会成为其余入侵中的一部分。例如，当一个零碎瘫痪时，攻打能够用来扩散服务器管理员的注意力，这样就容易疏忽零碎的其余中央正在被入侵。DDoS 攻打背地的策略可分为三类： 带宽过载系统资源过载利用软件谬误和安全漏洞带宽过载超载带宽的目标是令计算机无法访问。DoS 和 DDoS 攻打间接针对零碎网络及其各自的连贯设施。路由器一次只能解决肯定数量的数据，如果超出此容量，其余用户将无奈再应用服务。超载带宽中典型的 DDoS 攻打是 Smurf 攻打。 Smurf 攻打：这种 DDoS 攻打利用了 Internet 管制报文协定（ICMP），ICMP 的次要作用在于在计算机网络中替换信息和错误报告。攻击者将通过篡改的 ICMP 应答申请数据包（Ping）发送到网络的播送地址，应用指标的 IP 地址作为发件人地址；而后播送申请从路由器转发到所有连贯的设施，导致该网络的所有设施都对此 ICMP 应答申请做出回答，进而吞没受益主机，导致网络阻塞。更加简单的 Smurf 将源地址改为第三方的受害者，最终导致第三方解体。 系统资源过载针对 Web 服务器的 DDoS 攻打 是最为常见的。攻击者利用了 Web 服务器只能建设无限的数量连贯。如果这些链接被有效申请占用，那么就能无效地阻止失常用户申请。这就是 Flood 泛洪。针对系统资源的经典 DDoS 攻打模式有 Ping Flood、SYN Flood 和 UDP Flood。HTTP Flood：这是最简略的 DDoS 资源过载攻打的变体。攻击者通过大量 HTTP 申请吞没指标的 Web 服务器。他们只需拜访网页中任何一个元素，就能让服务器因申请量过载而解体。 ...

摘要Dubbo3 Triple 协定是参考 gRPC、gRPC-Web、Dubbo2 等协定特点设计而来，它汲取各自协定特点，齐全兼容 gRPC、Streaming 通信、且无缝反对 HTTP/1 和浏览器。 当你在 Dubbo 框架中应用 Triple 协定，而后你就能够间接应用 Dubbo 客户端、gRPC 客户端、curl、浏览器等拜访你公布的服务，不须要任何额定组件与配置。 除易用性以外，Dubbo3 Triple 在性能调优方面做了大量工作，本文将偏重对 Triple 协定背地的高性能机密进行深刻解说，波及一些有价值的性能调优工具、技巧及代码实现；在下一篇文章中，咱们将具体开展 Triple 协定在易用性方面的一些具体应用场景。 为什么要优化 Triple 协定的性能？自 2021 年开始 Dubbo3 就曾经作为下一代服务框架逐渐开始取代阿里外部宽泛应用的 HSF 框架，截止目前，阿里以淘宝、天猫等电商为代表的绝大多数外围利用曾经胜利降级到 Dubbo3。作为过来两年撑持阿里双十一万亿级服务调用的要害框架，Triple 通信协议的性能间接影响整个零碎的运行效率。 前置常识1.Triple 协定简介Triple 协定是参考 gRPC 与 gRPC-Web 两个协定设计而来，它汲取了两个协定各自的个性和长处，将它们整合在一起，成为一个齐全兼容 gRPC 且反对 Streaming 通信的协定，同时 Triple 还反对 HTTP/1、HTTP/2。 Triple 协定的设计指标如下： Triple 设计为对人类敌对、开发调试敌对的一款基于 HTTP 的协定，尤其是对 unary 类型的 RPC 申请。齐全兼容基于 HTTP/2 的 gRPC 协定，因而 Dubbo Triple 协定实现能够 100% 与 gRPC 体系互调互通。当你在 Dubbo 框架中应用 Triple 协定，而后你就能够间接应用 Dubbo 客户端、gRPC 客户端、curl、浏览器等拜访你公布的服务。 ...

阿里云函数计算中的 HTTP 触发器反对 SSE，能够通过设置 x-ali-apigw-sse: on 头来启用 SSE，确保您的函数代码也可能解决 SSE 音讯。 同时，建议您在返回头中增加 Content-Type: text/event-stream 以确保客户端正确解析 SSE 音讯。 残缺内容请点击下方链接查看： https://developer.aliyun.com/ask/498688 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

应用场景： 顺利的将网站迁徙到新的域名用户通过不同的网址拜访该网站，能够应用重定向将所有来自其余几个网址的流量转到指标网页合并两个网站时，确保将旧网址的链接重定向到正确的网页移除了某个网页，并心愿将用户转移到新网页永恒重定向在搜寻后果中显示新的重定向指标301和308状态码示意网页永恒的迁徙到新的地位 长期重定向在搜寻后果中显示源网页302长期重定向meta refresh即时重定向：在浏览器加载网页立刻触发，google会将即时 meta refresh重定向解析为永恒重定向。提早重定向：仅在网站所有者设置的任意秒数后触发，google搜寻会将提早meta refresh重定向解析为长期重定向。可将meta refresh置于html的head元素中，或置于http的响应标头中；<meta http-equiv="refresh" content="5; url=https://example.com/newlocation">HTTP/1.1 200 OKRefresh: 5; url=https://www.example.com/newlocationjavaScript location 重定向如需设置javascript重定向，在html head内将location属性设置为重定向指标网址；https://github.com/linround/gitBook/blob/main/SEO/web-redirects.md

302和301都是HTTP状态码，它们示意资源的重定向操作。 302状态码示意长期重定向，当服务器接管到客户端的申请后，会将申请的URL长期重定向到另一个URL，也就是重定向的指标URL，有时候也称之为“Found”状态码。长期重定向意味着申请的URI在将来可能会再次更改，因而搜索引擎对重定向次数和频率都有限度。 而301状态码示意永恒重定向，当服务器接管到客户端的申请后，会将申请的URL永恒重定向到另一个URL，也就是重定向的指标URL，因而被重定向的网址将不再被索引。301状态码是有利于搜索引擎优化的，能够让搜索引擎更好地抓取网页内容，所以很多网站在将原有的网址更改时，常常抉择应用301重定向。 总的来说，如果是长期的重定向，那么就能够应用302状态码；如果是永久性的重定向，那么就应该应用301状态码。

HTTP 与 RPC 接口是两种常见的接口通信协议。本文将会介绍它们的定义，区别和相同之处，利用场景以及目前的技术发展趋势，并给出接口代码示例和开发常用工具。 HTTP 接口HTTP（Hypertext Transfer Protocol）是一种应用层协定，它次要用于在 Web 浏览器和服务器之间传递数据。HTTP 的外围是客户端向服务器发动申请，并期待服务器响应。在 Web 利用中，HTTP 次要用于传输 HTML、CSS、JavaScript 和其余 Web 资源。 在接口设计中，HTTP 接口通常应用 RESTful 架构。RESTful 架构是一种设计格调，它应用 HTTP 办法（GET、POST、PUT、DELETE 等）和 URI（Uniform Resource Identifier）来定义资源和操作。通过应用 RESTful 架构，HTTP 接口能够具备良好的可读性、可维护性和可扩展性。 以下是一个 HTTP 接口的示例代码，应用 Python 的 Flask 框架实现： 在该示例中，定义了一个 HTTP 接口 /hello，通过 GET 办法传递参数 name，返回一个 JSON 格局的音讯。 RPC 接口RPC（Remote Procedure Call）是一种近程过程调用协定，它容许客户端应用程序通过网络调用近程服务器上的过程或函数。RPC 接口通常应用二进制协定来进行通信，例如 Protocol Buffers、Thrift、Msgpack 等。 在接口设计中，RPC 接口通常应用接口定义语言（IDL）来形容接口。IDL 是一种用于形容接口和数据结构的语言，它能够将接口和数据结构定义转换为多种编程语言，使得不同编程语言之间的接口通信更加不便。 以下是一个 RPC 接口的示例代码，应用 Protocol Buffers 和 gRPC 框架实现： 在该示例中，定义了一个 RPC 接口 Greeter，蕴含一个办法 SayHello，输出参数为 HelloRequest，输入参数为 HelloReply。 ...

前言系列首发于公众号『前端进阶圈』 ，若不想错过更多精彩内容，请“星标”一下，敬请关注公众号最新消息。前端面试实录HTTP篇1. http ~ http3.0？http 带宽提早浏览器阻塞(HOL blocking)DNS 查问(DNS lookup)建设连贯(initial connection)http1.0 无奈复用：每次申请都会与服务器建设一次连贯，耗费传输很大，队头阻塞：如果有多个申请，前一个申请的响应后果后能力发送下一个申请。所以所有的申请都会在先进先出的队列中，如果队头意外阻塞，就会造成队头阻塞问题。http1.1 缓存管制：新增了 ETag, Last-Modified, Expires，Cache-Control 来管制缓存长连贯：通过设置 Connection: keep-alive 属性来放弃 http 连贯能够在一个 TCP 连贯上发送多个申请分块传输管线化：将多个申请整批提交，在发送申请过程中也不须要期待服务器的响应http2.0 二进制分帧 Binary Format：http2.0 的根本单位是二进制，之前采纳的文本的形式传输，健壮性不是很好，后续改用了二进制的格局，更不便更强壮。多路复用 MultiPlexing: http2.0 的多路复用是把多个申请当做多个流，申请响应数据分成多个帧，不同流中的帧交织发送，解决了 TCP 连贯数量过多，TCP 连贯慢的问题，所以，在同一个域名中只须要创立一个连贯即可。header 压缩 header compress: http2.0 压缩了 header, 防止了反复申请头的传输，并缩小了传输的大小。服务端推送 server push: http2.0 的服务器推送，浏览器发送申请后，服务器会被动寻找与这个申请相干的资源，将这些资源和这个申请一并返回，这样，浏览器后续就不须要在申请，也缩小了申请次数。申请优先级 request prioritization：http2.0 能够设置申请的优先级，可依照优先级来解决队头阻塞的问题http3.0 0RTT 建设平安连贯: 基于 DH 密钥替换算法，在一个数据包中就能够蕴含无效的利用数据，从而在连贯提早上有所晋升，可节约数百毫秒的工夫连贯迁徙: http3.0 是基于 UDP 来实现的，简略来说，咱们切换 wifi 和 4G 时，不同基站之前不会造成重连的问题，从而进步了各种体验。队头阻塞问题: 一个数据包影响了一堆数据包，从而造成队头阻塞问题新的拥塞机制: 改用了 UDP 的形式，也就相应的改了 UDP 的拥塞机制前向纠错：QUIC 每发送一组数据就对这组数据进行异或运算，并将后果作为一个 FEC 包发送进来，接管方收到这一组数据后依据数据包和 FEC 包即可进行校验和纠错。个性热插拔：因为外围能力都在用户态实现的，不依赖内核，调整拥塞控制算法等行为都变得更为简略前向平安问题: 前向平安指的是密钥透露也不会让之前加密的数据被透露，影响的只有以后数据，对之前的数据无影响。2. GET 和 POST 的不同点？GET 申请参数会保留在浏览器记录历史汇总，而 POST 申请参数不会保留GET 只承受 ASCII 字符串，而 POST 没有限度，也能够二进制GET 申请产生一个 TCP 数据包，而 POST 产生两个 TCP 数据包GET 申请可增加为书签，而 POST 申请不能够GET 申请有长度限度，而 POST 申请没有限度GET 申请不是很平安，因为会一些参数显示在 URL 地址栏上，而 POST 申请不会，但也不是很平安，如果传输敏感数据，要进行数据加密GET 申请个别用来获取资源，可适当进行申请缓存，而 POST 不行，POST 是更新/获取资源，必须要与数据库交互，所以不能应用缓存3. 常见的 HTTP 办法？GET: 获取资源POST: 创立/更新资源PUT: 更新资源HEAD: 相似于 GET, 但响应式不是数据，而是 HTTP 的 header 信息DELETE: 删除资源OPTIONS: 容许客户端查看服务器的性能TRACE: 回显服务器收到的申请，用于测试和诊断COPY: 申请服务器将指定页面拷贝到另一个地址LINK: 申请与服务器建设连贯UNLINK: 断开与服务器的链接关系4. HTTP 与 HTTPS 的共同点与不同点？共同点： ...

本文咱们将介绍 Apache Dubbo 灵便的多协定设计准则，基于这一设计，在 Dubbo 框架底层可灵便的选用 HTTP/2、HTTP/REST、TCP、gRPC、JsonRPC、Hessian2 等任一 RPC 通信协议，同时享受对立的 API 与对等的服务治理能力。同时，咱们还介绍了 Dubbo 的单端口多协定能力，也就是在单个端口同时监听、解决多个协定，这对于简化多协定同时公布的场景十分有用。 不绑定 RPC 协定的设计准则Dubbo 框架不绑定任何通信协议，你能够依据业务场景抉择 HTTP/2 通信协议，也能够选用 HTTP/REST、TCP（Dubbo2）、gRPC、JsonRPC、Hessian2 等官网反对的通信协议，如果以上协定都不能满足需要，还能够十分不便的通过定制形式接入自定义协定。如果你想在一个利用内应用多个协定，也能够非常容易的做到，比方一个接口应用 HTTP/2 通信，另一个接口应用 TCP 通信，一个利用内公布或调用多个应用不同协定的服务。 通过 Dubbo 框架的多协定反对，你能够做到： 将任意通信协议无缝地接入 Dubbo 服务治理体系。Dubbo 体系下的所有通信协议，都能够享受到 Dubbo 的编程模型、服务发现、流量管控等劣势。比方 gRPC over Dubbo 的模式，服务治理、编程 API 都可能零老本接入 Dubbo 体系。兼容不同技术栈，业务零碎混合应用不同的服务框架、RPC 框架。比方有些服务应用 gRPC 或者 Spring Cloud 开发，有些服务应用 Dubbo 框架开发，通过 Dubbo 的多协定反对能够很好的实现互通。让协定迁徙变的更简略。通过多协定、注册核心的协调，能够疾速满足公司内协定迁徙的需要。比方如从自研协定降级到 Dubbo 协定，Dubbo 协定本身降级，从 Dubbo 协定迁徙到 gRPC，从 HTTP 迁徙到 Dubbo 协定等。官网接入的支流协定HTTP/2 (Triple)Triple 协定是 Dubbo3 公布的面向云原生时代的通信协议，它基于 HTTP/2 并且齐全兼容 gRPC 协定，原生反对 Streaming 通信语义，自 Triple 协定开始，Dubbo 还反对基于 Protobuf 的服务定义与数据传输。Triple 具备更好的网关、代理穿透性，因而非常适合于跨网关、代理通信的部署架构，如服务网格等。Triple 协定的外围个性如下： ...

上文给大家具体介绍了在 Apinto 上实现 HTTP 与 gRPC 的协定转换的根本内容，本篇咱们将持续解说如何在 Apinto-Dashboard 中进行配置。 配置 ApintoApinto 上咱们提供了可视化界面工具 Apinto-Dashboard，以升高初学者的应用老本，以下操作均在 Apinto-Dashboard 中进行配置。 1. 在全局插件中新建 http_to_grpc 插件 2. 创立 gRPC 服务 在这里，咱们配置 gRPC服务的相干信息，咱们能够配置多个动态负载地址，这里咱们填写了 127.0.0.1:9001。 3.创立 http 路由，绑定 grpc_demo 上游服务 4. 在路由中绑定 http_to_grpc 插件 因为 gRPC 服务端示例中，咱们开启了gRPC反射，因而，在配置插件时，开启反射按钮即可 注： 当服务名称不填时，则默认应用  HTTP 申请门路的第一个/ 和第二个 / 之间的值作为服务名；当办法名称不填时，则默认应用  HTTP 申请门路的第二个 / 和第三个 / 之间的值作为服务名；即，若 HTTP 申请门路上 /Service.Hello/Hello ，则此时服务名称为 Service.Hello ，办法名称为 Hello 。 对于 Protobuf 编码器若gRPC未开启反射，咱们须要先新建一个Protobuf 编码器，绑定 http_to_grpc 插件时，绑定对应的编码器 ID 即可，具体步骤如下： ...

Content-type类型在HTTP协定音讯头中，应用Content-Type来示意媒体类型信息。它被用来通知服务端如何解决申请的数据，以及通知客户端（个别是浏览器）如何解析响应的数据，比方显示图片，解析html或仅仅展现一个文本等。 Post申请的内容搁置在申请体中，Content-Type定义了申请体的编码格局。数据发送进来后，还须要接收端解析才能够。接收端依附申请头中的Content-Type字段来获知申请体的编码格局，最初再进行解析。开发过程中次要有如下几种content-type类型： text/xml 该种形式次要用来提交XML格局的数据。application/x-www-form-urlencoded浏览器的原生form表单，如果不设置enctype属性，那么最终会以applicatiion/x-www-form-urlencoded形式提交数据。这种形式提交数据放在body外面，数据依照key1=value1&key2=value2的形式进行编码。 multipart/form-data这种形式也是常见的post提交形式，通常表单上传时应用该办法。application/json通知服务器主体的序列化的json字符串。应用场景开发过程中次要用到“application/x-www-form-urlencoded”、“application/json”、“multipart/form-data”三种类型，上面咱们就来具体说说这三种类型的构造和在SpringMVC中的应用场景： ### 1. application/x-www-form-urlencoded 当action为get时候，浏览器用x-www-form-urlencoded的编码方式把form数据转换成一个字串（name1=value1&name2=value2…），而后把这个字串append到url前面，用?宰割，加载这个新的url。 当action为post时候，浏览器把form数据封装到http body中，而后发送到server 客户端： header：Content-Type=application/x-www-form-urlencoded Method：get办法-参数须要做URLEncode Post办法-构建nameValuePairList列表放入UrlEncodedFormEntityList<NameValuePair> nameValuePairList = new ArrayList<~>(); nameValuePairList.add(new BasicNameValuePair( name: "name", value: "zhangsan")); nameValuePairList.add(new BasicNamevaluePair( name: "birthday" value: "1990-08-25")); UrlEncodedFormEntity entityParam = new UrlEncodedFormEntity(namevaluePairlist， charset: "UTF-8"); post.setEntity(entityParam);服务端： 申请参数不含MultlpartFile类型时可同时反对 GET和POST，具体请参考以下标准： controller办法注解@RequestMapping(method = {RequestMethod.POST, RequestMethod.GET}) 上传文件：只反对POST（包含MutipleFile和Base64字符串） 办法参数能够对象形成：不能加@RequestBody注解，否则不能接管到 @RequestMapping(value = "/testParamForm", method = {RequestMethod.POST,RequestMethod.GET}) @ApiOperation("Content-type:application/x-www-form-urlencoded, 同时反对POST和GET，多个申请参数，无上传文件， URL和body的申请参数能够失常获取，URL的参数encode转码 ") @ApiResponses(value={@ApiResponse(code = 200, message = "申请胜利")}) public Result testParamForm(String name, String idcard){ log.info("name:{}, idcard:{}", name, idcard); return ResultUtil.success(); }如果是申请参数超过3个以上，能够封装成申请参数对象： ...

HTTP 是一种基于申请-响应模型的网络通信协定，次要用于 Web 中客户端和服务器之间通信的数据传输。事实上，现在的互联网就是构建在 HTTP 之上的。基于申请-响应模式的通信形式很简略，客户端向服务器发送申请，服务器解决申请并进行响应。HTTP 其实并不关怀咱们想要传输的是什么类型的数据，因为它什么类型的数据都能够传输！对于客户端或者服务器来说，只须要设置好适合的 Content-Type，让另一端可能了解数据就能够了。在一个申请中，客户端发送给服务器的数据能够是文本，也能够是图片或者音视频等等。如果客户端想在一个申请中给服务器发送多种类型的数据呢，该怎么办呢？例如，同时发送用户的根本信息和头像。办法很简略，就是应用 HTTP 的 multipart。 Multipart 音讯构造Multipart 容许客户端在一次 HTTP 申请中发送多个局部（part）数据，每局部数据之间的类型能够不同。Multipart 并不是一种专一的数据类型，它有很多子类型，例如：multipart/mixed，multipart/form-data 等。艰深来讲，一个 multipart 音讯就是一个大包裹，包裹外面有多个不同类型的音讯，每一个音讯就是一个 part，每个 part 都会申明本人的音讯类型（Content-Type）。除了音讯类型，part 还能够附加一些元数据。Multipart 音讯的根本语法结构能够在 RFC2046 中找到： 每个 multipart 音讯的 Content-Type 都必须蕴含一个叫做 boundary 的参数，boundary 申明了各个 part 之间的边界，记为 ${boundary}。实际上，残缺的边界定义为：一行由两个 - 加上 ${boundary} 组成的字符串。假如咱们在 Content-Type 外面指定的 boundary=example-part-boundary，那么依照协定规定，每个 part 之间的分隔行就是：--example-part-boundary。每个边界之后是一个 CRLF 加下一个 part 的头部信息。如果下一个 part 没有头部信息，边界之后就应该跟两个 CRLF，这样下一个 part 的音讯类型就会被认为是 text/plain。${boundary} 不能呈现在边界之间，并且长度不能超过 70 个字符。最初一个 part 之后的边界在开端多了两个 -，示意前面不会再有其它的 part 了。这个边界的残缺格局为：--${boundary}--，例如 --example-part-boundary--。咱们会在前面讲 multipart/form-data 给出一个具体的示例。 multipart/form-dataMultipart 的应用在 Web 应用程序中很常见。应用 multipart 频率最高的中央大略就是 Web 表单了，在表单提交时，文件的上传就是通过 Multipart 来实现的。并不是所有的表单提交都会应用 multipart，如果表单只蕴含基于文本的输出组件（例如输入框、单选框等），浏览器会将这些数据以 key=value 的模式组织，应用一种被称为 application/x-www-form-urlencoded 的 Content-Type 传输。如果表单中蕴含文件或图片等不能被编码成文本的元素，浏览器就会应用 multipart/form-data 向服务器传输数据。 ...

一、在HTTP中，PUT和POST办法都是用来向服务器提交数据的，但它们在理论应用中有一些区别.1、性能不同办法区别点putPUT办法是用来更新资源的，客户端发送的数据会替换掉服务器上对应资源的全部内容。如果该资源不存在，则会被创立。postPOST办法则是用来提交新资源或对现有资源进行局部更新的，客户端发送的数据会被附加到服务器上对应资源的开端。2、幂等性不同办法区别点putPUT办法是幂等的，即无论执行多少次都只会产生同样的后果，因为它总是用来更新特定的资源postPOST办法是非幂等的，因为屡次执行可能会产生不同的后果，例如每次提交的数据都会被追加到服务器上对应资源的开端3、编辑时的不同办法区别点putPUT办法要求客户端提供残缺的资源内容，即便只是对资源的局部批改也须要将残缺的内容发送到服务器上postPOST办法则容许客户端只提交须要批改的局部数据二、http的put办法是否能够用于新增操作？在HTTP协定中，PUT办法的次要目标是更新或替换服务器上的资源。因而，从协定标准上来说，PUT办法不应该用于新增操作。 如果要进行新增操作，应该应用POST办法，因为POST办法的次要目标是在服务器上创立一个新资源或对现有资源进行批改。POST办法能够在申请体中蕴含要新增的资源数据，并且在服务器端创立新的资源，并返回资源的URI（Uniform Resource Identifier）。 尽管PUT办法的次要目标是更新或替换资源，然而在某些状况下，PUT办法也能够用于新增操作。例如，在应用RESTful API（Representational State Transfer）时，能够应用PUT办法来创立新资源。然而，在这种状况下，创立新资源的操作通常须要在URI中指定资源的ID或者应用其余形式来惟一标识新资源。

给个需要：通过HTTP协定来获取指定网页的图片，并下载到本地，且用照片的名字来命名照片。这里我就拿学校的官网来作为指定网页，来实现下载官网图片的性能。至于如何用HTTP协定制作一个繁难的客户端，能够参考我之前写的一篇文章：手写一个繁难的安卓客户端：https://segmentfault.com/a/1190000043478702 如何获取官网上的图片信息。首先咱们要晓得，咱们该如何获取网页上的图片信息。咱们通过申请服务器展现图片的网页的相干门路，服务器就会返回一个HTML页面的响应。而这个HTML页面里就有许许多多的<img>标签，图片的相干信息就寄存在这个标签之中。以我学校的官网举例：所以咱们要做的事件就是利用正则表达式来提取HTML页面中<img>标签。 1、创立一个繁难的http客户端类，连贯到指定的服务端 public class Client { private int port = 80 ;//这个是http协定的默认端口号 private String host = "指定网页的近程地址"; String url; public Client(){ } public Client(int port,String host){ this.port = port; this.host = host; } public void clientServer() throws IOException{ System.out.println("连贯上服务器"); Socket socket = new Socket(host, port); } public void writeToServerGET(OutputStream clientOut,String url ,String host,int port) throws IOException { clientOut.write(("GET" +" "+url+" "+"HTTP/1.1"+"\r\n").getBytes()); clientOut.write(("Accept:"+" "+"text/html"+"\r\n").getBytes()); clientOut.write(("HOST:"+" "+ host+":"+port+"\r\n").getBytes()); clientOut.write(("Connection: "+"keep-alive"+"\r\n").getBytes()); clientOut.write("\r\n".getBytes()); clientOut.flush(); } public static void main(String[] args) throws IOException { new Client().clientServer(); }}2、在Client类中创立读取输出流的办法readResponse()办法 ...

转载于海内博客：https://scriptrunz.com/zh-cn/... HTTP 报文头HTTP 报文头也叫报文首部。 HTTP 头部字段是形成 HTTP 报文的因素之一。在客户端与服务器之间以 HTTP 协定进行通信的过程中，无论是申请还是响应都会应用头部字段，它能起到传递额定重要信息的作用。 HTTP 首部字段是由首部字段名和字段值形成的，两头用冒号:分隔，上面是一个 HTTP 报文头的例子： GET / HTTP/1.1Host: hackr.jpUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Ge Accept: text/html,application/xhtml+xml,application/xml;q=0 Accept-Language: ja,en-us;q=0.7,en;q=0.3Accept-Encoding: gzip, deflateConnection: keep-aliveIf-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT If-None-Match: "45bae1-16a-46d776ac"Cache-Control: max-age=0看不懂这些字段代表什么意思对吧？读完本文就全弄懂了。 通用首部字段通用首部字段是指：申请报文和响应报文单方都会应用的字段。 Cache-ControlCache-Control 通过设置不同的指令能够管制缓存的行为，指令格局为： Cache-Control: no-cache Cache-Control: no-storeCache-Control: max-age=<seconds>指令参数大略能够分为三类： 管制可缓存性。管制到期工夫。管制从新验证&从新加载。管制缓存no-cache 会强制验证数据的有效期，以避免获取到过期资源。no-store 会禁止缓存服务器缓存数据。（个别意味着数据中含有机密信息only-if-cached：仅从缓存服务器获取数据，保障申请绝不会达到源服务器，如果缓存服务器没有该资源，则返回状态码504（GateWay Timeout）。public：表明响应能够被任何对象（包含：发送申请的客户端，代理服务器，等等）缓存private：表明响应只能被单个用户缓存，不能作为共享缓存（即代理服务器不能缓存它）。管制到期工夫max-age：设置缓存存储的最大周期，超过这个工夫缓存被认为过期 (单位秒)。客户端只接管缓存工夫<max-age的数据。s-maxage：笼罩 max-age 或 Expires 字段，但它只实用于共享缓存（例如代理服务器），公有服务器会疏忽这个字段。max-stale：示意客户端违心接管一个过期的资源，只有资源的过期工夫<max-stale的值。min-fresh：示意客户想要的资源至多在指定的秒数内依然是陈腐的。HTTP/1.1 版本的缓存服务器遇到同时存在 Expires 首部字段的状况时，会优先解决 max-age 指令，而疏忽掉 Expires 首部字段。而 HTTP/1.0 版本的缓存服务器的状况却相同，max-age 指令会被疏忽 ...

HTTP协定HTTP能够在任何互联网协议上，或者其余网络上实现。HTTP假设其上层协定提供牢靠的传输，因而任何能提供这种保障协定都能够被其应用。因而，也就是其在TCP/IP协定簇中应用TCP作为传输层。 通常，由HTTP客户端发动一个申请，创立一个到服务器指定端口的TCP连贯。HTTP服务器则在那个端口监听客户端的申请。一旦收到申请，服务器就会向客户端返回一个状态，比方"HTTP/1.1 200 OK"，以及返回的内容，如申请的文件，谬误的音讯或者其它信息。 HTTP工作原理HTTP协定定义Web客户端如何从Web服务器申请Web页面，以及服务器如何把Web页面传送给客户端。HTTP协定采纳了申请/响应模型。客户端向服务器发送一个申请报文，申请报文蕴含申请的办法、URL、协定版本、申请头部和申请数据。服务器以一个状态行作为响应，响应的内容包含协定的版本，胜利或者错误代码、服务器信息、响应头部和响应数据。以下是HTTP申请/响应的步骤：1、客户端连贯到Web服务器一个HTTP客户端，通常是浏览器与Web服务器的HTTP端口建设一个TCP套接字连贯。2、发送HTTP申请通过TCP套接字，客户端向Web服务器发送一个文本的申请报文，一个申请报文由申请行、申请头部、空行和申请数据4局部组成。3、服务器接管申请并返回HTTP响应Web服务器解析申请、定位申请资源。服务器将资源复写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4局部组成。4、开释TCP连贯若connection模式为close，则服务器被动敞开TCP连贯，客户端被动敞开连贯，开释TCP连贯，若connection模式为keepalive，则该连贯会放弃一段时间，在该工夫能够持续承受申请。5、客户端浏览器解析HTML内容客户端浏览器首先解析状态行，查看表明申请是否胜利的状态代码。而后解析每一个响应头，响应头告知以下若干字节的HTML文档和文档字符集。客户端浏览器读取响应数据HTML，依据HTML的语法对其进行格式化，并在浏览器窗口中显示。 在浏览器的地址栏上输出一个地址会产生什么？在游览器上的地址栏上输出一个地址，产生了这些事件（不残缺）1、浏览器向DNS服务器申请解析该URL中的域名所对应的ip地址。2、解析出IP地址后，依据该IP地址和默认端口80，和服务器建设TCP连贯。3、浏览器收回读取文件（URL域名前面局部对应的文件）的http申请，该申请报文作为TCP三次握手的第三个报文的数据发送给服务器。4、服务器对浏览器做出响应，并把对应的html文本发送给浏览器。5、开释TCP连贯。6、浏览器将该html文本解析并显示内容。 HTTP协定是基于TCP/IP协定之上的应用层协定1、基于申请/响应的模式客户端——>服务端——>客户端2、无状态保留HTTP是一种不保留状态，及无状态协定。HTTP协定本身不对申请和响应之间的通信状态进行保留。也就是说在HTTP这个级别，协定对于发送过的申请或响应都不做长久化解决（引入Cookie技术来保留）3、无连贯每次连贯只解决一个申请，服务端解决完客户端的申请，并收到客户应答后，断开连接，当初的HTTP/1.1是期待几秒后断开（如果客户端还有申请，就持续用这个连贯，创立连贯也是须要资源工夫的）。 HTTP申请办法（定义了8种）1、GET2、HEAD3、POST4、PUT5、DELETE6、TRACE7、OPTIONS8、CONNECT其中最罕用的是GET和POST申请办法。1、GET提交的数据放在URL（协定、地址、端口、门路?查问、信息化片段）中的查问局部，以?来宰割（http://localhost:8080/happyfa...），参数之间以&相连。POST办法是把提交的数据放在HTTP的body当中。2、GET提交的数据大小有限度（不是GET自身的限度），POST办法没有限度。3、GET与POST申请在服务端获取申请数据的形式不同。 状态码1、200 OK 示意拜访胜利2、404 NOT Found 示意没有找到资源3、403 Forbidden 示意拜访被回绝4、405 Method Not Allowed 示意拜访的服务器不能反对申请核心的办法5、500 Internal Server Error 示意服务器外部呈现问题6、504 Gateway Timeout 示意以后服务器负载比拟大，服务器解决单条申请的时耗很长，呈现超时7、302 Move temporarily 示意长期重定向8、301 Moved Permanently 示意永恒重定向，当浏览器收到这种响应后，后续的申请都会被主动的改成新地址。 接下来咱们手写一个http服务器并且实现一个需要。

前言如果你在治理一些网站，那么对HTTP重定向的了解对于牢靠的网站性能至关重要。在这篇文章中，咱们将全面理解一下3xx HTTP状态码，从这里你能够理解它们是如何工作的，如何更好地治理它们，以及它们对SEO的影响。 HTTP重定向的目标URL重定向波及到一个网页地址被映射到另一个。网站须要重定向的起因有很多。 比如说，迁徙到一个新的域名是应用URL重定向的首要起因之一。有时，你以前的域名太长、太简单，导致难以记住，或者某种侵权流动迫使你从一个域名转移到另一个域名。 让咱们具体看看重定向页面的其余起因： 转发多个域名：当同时领有多个域名时，须要永恒的HTTP重定向，以疏导互联网用户和搜索引擎到同一地址。辨认破损链接：404页面能够通过Google Search Console来辨认。笼罩报告将给你提供所有链接的详细信息，以便在重定向的帮忙下进行修复。修复破损链接：在辨认破损链接后，你能够将其重定向到首页。然而，一个更好的抉择是将每个破损的URL重定向到一个具备雷同（相似）内容的新页面。页面的新地址：如果你的原网站有访问量很高的页面，在SERP中排名很高，重定向将帮忙你把这个URL映射到新的地址。对于这种状况，你必须确定你用于重定向的旧网页没有隐没。须要删除页面：为所有你须要删除的页面创立HTTP重定向，确保不要用404谬误来吓唬访客。重定向将向谷歌或其余搜索引擎发出信号，旧链接的链接值应调配给重定向的URL。除此之外，还有一些其余场景值得思考。如果你须要简化和跟踪显示广告或应答紧急情况，重定向将派上用场。重定向有助于营销人员监测广告反应。同时，网络管理员能够在重定向的帮忙下修复任何失败的链接流动。 总之，谷歌对重定向的定义是管制抓取和索引。谷歌搜寻核心将HTTP重定向解释为进行无缝过渡的做法，通过几个URL拜访一个页面，纠正过期的URL，并将用户从删除的页面重定向到新的页面，从而排除404谬误。 网络协议基础知识互联网上用于传输数据和信息管制的托管服务器的根本协定被称为HTTP。超文本传输协定容许万维网的互联网用户和服务器之间保护网站以及提供通信。 HTTP是用于不同类型数据的信息系统的协定：分布式、超媒体和合作式。HTTP的次要指标是提供基于互联网的无缝交互。 这种申请-响应协定通过TCP连贯工作。传输控制协议容许互联网与万维网上代表的任何可用辨认资源进行交互。用户与网页、视频和信息服务器的通信是通过HTTP进行的。这样，客户能够取得对网页的拜访。 值得注意的是，超文本传输协定应用代理。它们是用于内容辨认和剖析的非凡用处的过滤器。HTTP代理避免用户低质量地发送和显示文件： 特务软件的文本和图像畸形的多媒体文件网络攻击驱动的音频文件HTTP客户端是用来爱护用户的浏览器的。它向服务器发送申请信息。HTTP服务端负责HTTP响应连贯。HTTP代理的原理能够用以下形式来示意： HTTP协定的次要长处是： HTTP协定提供了先进的寻址计划。所有的IP地址在万维网上都变得容易辨认和确认。实现了在线资源的灵活性和可拜访性。HTTP为扩大和插件下载提供了机会。这样，相干的数据就会显示进去。HTTP共有九种申请办法来执行不同的网络操作。 申请形容PUT负责批改现存的网络资源。该申请也容许创立新的URL。HEAD创立一个非凡用处资源的申请，不须要任何主体内容。POST负责将现有资源批改的内容增加到新的网页上。DELETE删除指定资源。GET申请残缺资源。TRACE显示用户拜访的网络资源的任何更新和变动。OPTIONS展现用户能够拜访的HTTP办法列表。CONNECT负责将基于申请的连贯转换为TCP/IP隧道。PATCH使得对网络资源进行局部批改成为可能。状态码HTTP状态码是决定服务器响应的非凡元素。有必要理解每一个HTTP状态码，以明确问题并解决它们。 有五类状态码须要思考。有信息响应、胜利、重定向、客户谬误和服务谬误五种类别。第一个数字示意HTTP状态码的类别。让咱们认真看看每个响应的类别： 1xx信息响应：这类状态码告知了申请的接管状况。它意味着步骤持续。比如说，100示意continue。2xx胜利：这些状态码是对于对申请的了解和接管。比如说，200示意OK。3xx重定向：这类状态码示意须要一些非凡目标的动作来实现申请。比如说，301示意redirection。4xx客户端谬误：这类响应状态码标记着该申请不能进行。此外，它可能意味着申请中存在谬误的语法。比如说，400示意bad request。5xx服务端谬误：这类HTTP状态码是对于由服务器的失败解决造成的，不胜利的服务器响应。比如说，500示意internal error。值得注意的是，一些状态码和谬误对SEO有间接影响。尽管1xx和2xx对搜索引擎优化影响不大（有200响应是最好的做法），但3xx、4xx和5xx的会对抓取和索引你的网页产生负面影响。你应该始终留神解决4xx和5xx状态码和谬误，因为这对你网站的整体排名十分无害。 HTTP 300状态码兴许对SEO表演外围角色。这类状态码负责将所有的SEO价值从你的旧网址传递到新网址。因而，有必要开掘每个3xx状态码的含意（长期或永恒重定向、代理、多重选择，等等）。 3xx状态码3xx状态码示意不同类型的HTTP重定向。营销人员通常应用3xx状态码来监测和剖析用户体验、网站用户的行为以及网站的SEO性能。DataTracker资源确定了由3xx HTTP状态码衍生的四种重定向类型： 像301，302，307这样的重定向示意指标资源曾经被调配了一个新的URL。300重定向提供多种抉择（依据申请抉择匹配的网络资源）。303重定向提供了对已实现申请的间接响应，如果Location字段能够辨认的话。304重定向提供HTTP重定向到之前缓存的后果中。3xx状态码呈现在有必要表明服务器的重定向响应时。3xx HTTP状态码的另一个例子是为被删除的页面放弃其排名。此外，当有必要修复破损的URL时，重定向也会派上用场。 当谬误产生时，重定向不冀望看到其余响应码。例如，重定向不能解决1xx、4xx、5xx的问题（Not Implemented = 501；Bad Gateway = 502；Unprocessable Entity = 420）。 上面就让咱们认真看看每个3xx状态码，理解它们对SEO和网站排名的影响。 300 Multiple Choices这些状态码通常用于REST APIs。给予浏览器多种抉择，它应该在满足申请的资源中进行抉择。例如，如果你有多个视频格式选项或不同的文件扩展名须要指定，300状态码就会派上用场。 应用300重定向另一个起因是，为了满足内容协商的要求。服务器告诉用户代理可用的示意类型供其抉择。认真看一下这个例子，看看300重定向的作用。 HTTP/1.1 300 Multiple ChoicesServer: curveball/0.3.1Access-Control-Allow-Headers: Content-Type,User-AgentAccess-Control-Allow-Origin: *Link: </foo> rel="alternate"Link: </bar> rel="alternate"Content-Type: text/htmlLocation: /foo你能够在代码中看到/foo和/bar。当两个选项都能够抉择时，地址就被指定了。 301 Moved Permanently还有一个状态码通常用于REST APIs中。该状态码次要作用是，永久性的重定向。如果你须要在短时间内应用重定向，301重定向就不适宜。在301 HTTP状态码的帮忙下，互联网用户和搜索引擎都被带到一个新的URL。该类型的最佳重定向计划是以后一个页面不打算复原的时候。 让咱们借助一个实在的案例来解释永恒HTTP重定向的概念： FAQ页面托管在子域名上面（https://faq.website.com）。你决定挪动FAQ页面到子文件夹下（https://www.website.com/faq/）。如果子域名被删除了，404页就会侵害网站的SEO。用户体验也受到影响，所以重定向是必须的。搁置一个301重定向，避免用户拜访旧的URL。搜索引擎也将被重定向到新的FAQ页面。让咱们再看个永久性重定向的例子（301重定向）。在这里咱们能够看到一个301 HTTP状态码，用于将用户和搜索引擎重定向到新的地址。 程序员常常应用.htaccess文件来实现不同类型的重定向，包含301重定向。有两种301重定向的办法须要思考到： 整个域名能够被重定向到一个新的网站。在Redirect 301后增加你感兴趣的域名： Redirect 301 /[http://www.website.com/](http://www.website.com/)如果你只想重定向一个页面，有必要在Redirect 301前面指定旧的URL： ...

HTTP协定默认是采取明文传输的，容易被中间人窃听、拦挡、篡改，存在安全隐患。 常见进步安全性的办法是对通信内容进行加密，再进行传输，常见的加密形式有 不可逆加密：单向散列函数可逆加密：对称加密、非对称加密其它组合加密：混合明码、数字签名、证书单向散列函数单向散列函数是一种不可逆的加密形式，加密后不能再解密将数据恢复原样，通过单向散列函数依据依据音讯内容计算出散列值，无论音讯的长度、大小是多少，最终生成的散列值长度都是固定值。 常见的散列函数有 MD5、SHA，尽管说具备单向性，但依然有些网站能够暴力破解较为简单的内容。 但加密的原始内容更为简单的话，破解的可能性就会较为小一些，比方开启大小写+字符的形式。 不可逆的加密形式可用于保留一些不须要还原的敏感信息，比方用户的明码，如果明文寄存无论是开发者、网络保护人员看到、或者被黑客攻击都会存在信息泄露的问题，那么加密保留便是一种比拟适合的形式。 比方当用户注册时，保留的明码是通过单向散列函数加密寄存在数据库的，当用户登录时，将输出的明码加密后和数据库中保留的进行比拟。即便用户遗记明码，也无需思考还原原明码，让用户从新设置新密码即可。 对称加密在对称加密中，加密、解密时应用的是同一个密钥。 对称加密算法罕用 DES、3DES、AES 对称加密密钥如何配送依然会存在问题，除非私下共享，只有通过网络明文传输，都存在被拦挡窃取的可能。 咱们换个思路，是否存在一种加密形式，即便配送密钥的被窃取了，也不必放心，因为单单只用一个密钥不会影响数据传递。非对称加密就是这样，加密和解密都须要公钥和私钥两个密钥独特合作。 非对称加密在非对称加密中，密钥分为加密密钥和解密密钥，两者并不相同，加密密钥个别是公开的，因而也称为公钥，解密密钥由音讯接收者本人保存，不能公开，也称为私钥。 公钥和私钥是一一对应的，不能独自生成，一堆公钥和私钥统称为密钥对，由公钥加密的密文，必须应用与该公钥对应的私钥能力解密，由私钥加密的密文，必须应用与该私钥对应的公钥能力解密。 这样，应用非对称加密便能够解决密钥配送问题，由接收者生成密钥对，将公钥配送给音讯发送者，发送者通过公钥加密音讯后，发送密文给接收者，接收者再通过私钥解密音讯。 在这个过程中，即便音讯、公钥被中间人窃听也没关系，因为公钥加密的音讯只可通过对应的私钥解密，而私钥是保留在接收者处的。 非对称加密比拟平安，解决了密钥的配送问题，但它的加密速度比对称加密要更慢一些，如果所有内容都采纳非对称加密，那网络上通信将变得十分慢。 混合明码混合明码是将对称加密和非对称加密劣势相结合的办法，解决了对称加密的密钥配送，非对称加密速度慢的问题。 应用对称加密将音讯加密，再通过非对称加密算法加密对称加密的密钥，这样就能保障简单的内容应用加密较快的对称加密，而重要的信息通过非对称加密。 数字签名以上形式从接收者的角度，能够保障音讯的在传输过程的平安，但如何能保障起源的可靠性呢？如果被窃听，中间人也是能够通过公钥加密伪造音讯发送给接收者的。 数字签名 就是一种保障起源的形式，与以上混合加密不同，是由音讯发送者的私钥生成签名，由音讯接收者通过公钥验证签名。 音讯是明文传输不平安，并且应用非对称加密所有的音讯会比拟耗时，能够改良为应用散列函数将音讯加密，再通过私钥对散列函数加密，因为散列函数不可逆能够解决平安问题，并且散列函数解决过的数据长度是一个比拟短的固定值，能解决耗时的问题。 证书公钥的配送依然可能存在问题，如果存在中间人窃听了公钥，能够本人生成一套密钥对，并将本人的公钥传递给音讯发送方。 为了保障公钥的安全性，能够依附于认证机构来颁发数字签名。 总结单向散列函数不可逆，加密后长度固定对称加密解密应用的是雷同的密钥，加密速度较快，但密钥的配送存在平安问题非对称加密存在密钥对，分为加密密钥公钥和解密密钥私钥，加密速度较慢混合明码联合对称加密和非对称加密，同时做到平安和较快的加密速度数字签名用于确认音讯的完整性，辨认音讯是否被篡改证书保障公钥的平安以上就是各种加密形式，以解决HTTP协定带来的平安问题。更多无关 前端、网络协议 的内容能够参考我其它的博文，继续更新中~

HTTPS是平安通道。如果浏览器导航栏后面有一个绿如A股的小锁，那么感觉就会十分的释怀。把本人见不得人的小心理和污言秽语，通通用这个小锁锁起来，随心所欲，想想就让人冲动。然而等等，Charles为什么能抓到HTTPS的包呢？HTTPS简略原理咱们心愿数据传输过程，对用户来说是个黑盒，对攻击者来说也是个黑盒。这次要体现在两方面。 用户不心愿本人的敏感数据被获取到。比方本人的账号密码，比方本人发给女友的聊骚数据。开发者不心愿本人的数据被用户获取到。比方本人的验签形式，被破解了用户就无能很多非法的事件。 HTTP协定属于一问一答的协定，在传输过程中是以明文形式传递的。如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就能够间接读懂其中的信息。比方通过代理形式或者局域网嗅探形式获取了报文的内容。相干的工具有很多，比方wireshark、tcpdump、dsniff等。 但如果传输的内容是加密的，那么即便你把所有的数据报文都抓到了，那么也没有什么价值。HTTPS就是一种传输加密数据的协定。如果咱们在TCP与HTTP两头，退出一个TLS/SSL层，那么就会变成HTTPS。HTTPS包含握手阶段和传输阶段。其中握手阶段是最重要的协商阶段。握手的指标，是平安的替换对称密钥，全程须要3个随机数的参加。在Change Cipher Spec之后，传输的就都是加密后的内容了。这个过程能够应用WireShark抓包工具轻易抓取，有大量的文章剖析握手过程，在此不再赘述。 当然，HTTPS的效率是非常低的。这里略微扩大一下。HTTP3，也就是谷歌的QUIC，除了解决了队头阻塞问题，还能够作为TCP+TLS+HTTP/2的一种代替计划。HTTP3默认就是平安通道，采纳UDP协定。在DH秘钥替换算法的加持下，它能够缩小连贯建设工夫 - 在常见状况下为 0 次RTT往返。这比HTTPS的握手速度快多了。 Charles抓包尽管HTTPS的传输过程是加密的，但如果咱们就是申请的发起方，设施也在本人手里，去抓包HTTPS连贯中的内容，也是非常容易的。这让开发者很头疼。比方我应用云平台提供的AK、SK间接发动HTTPS调用，用户是可能抓到这两个要害明码的。所以个别开发者并不能间接把AK、SK在网络上传递，即便这样在性能上行得通。我这里以在MacOS本机上抓包浏览器的HTTPS申请为例，来阐明Charles的应用。启动Charles后，咱们须要把它设置成零碎代理。 而后，在Help/菜单下，找到Root证书进行装置。 装置结束之后，咱们还要信赖这个证书。这样，当你的浏览器拜访咱们的Charles代理时，就能够畅通无阻。装置到System Keychains中，而且肯定要信赖它哦。 通常状况下，我拜访一个HTTPS连贯，抓到的内容都是一团糟。 咱们还差最初一步。默认状况下，Charles并没有任何过滤，我么还须要把要抓包的网址，退出HTTPS的代理配置中才能够。右键找到这个连贯，而后抉择启动SSL代理即可。 此时，咱们再看一下这些连贯的内容，就可能变成人眼可能辨认的了。 当然，电脑上的代理没有什么意义。咱们做代理，个别是想要抓取手机上的利用产生的申请。但办法是一样的，你只须要把这个Root证书，装置到你的手机中，而后信赖它就能够了。为什么可能抓到数据？在这个案例中，Charles是作为中间人而存在的。对于Charles来说，对于服务端的申请，是由它发动的。你能够把它设想成一个浏览器，它收回的申请和返回的内容，对于Charles本身来说天然是可见的。坑骗服务器很容易，重要的坑骗客户端。Charles通过伪造一个CA证书，来假冒一个服务端。当浏览器或者挪动手机拜访Charles假冒的服务端时，Charles会携带CA证书返回给客户端。对于一般的CA证书来说，浏览器和客户端是不信赖的。这也是为什么要进行HTTPS抓包，必须装置CA证书的起因---咱们须要把这个信赖关系建设起来。这两局部是割裂的，能够说是由两条齐全不同的SSL通道。申请报文在全程是加密的，除了一个十分单薄的交接点。在通道的粘合处，所有的信息却是明文的。Charles掌控了这个过程，天然就可能把原始信息展现进去。End能够看到，Charles是能够抓取到HTTPS的明文信息的。在中间人场景中，它既作为客户端发动申请，也作为服务端接管申请，而后在申请的转发处获取数据。作为用户，咱们千万不能随便信赖来历不明的证书，否则你的很多隐衷数据将裸露在阳光之下。作为开发者，也不能把敏感数据间接放在URL或者申请体里，避免用户抓包获取到这些信息，对服务造成毁坏。当然，在CN，隐衷可能是个伪命题。就比方xjjdog，尽管我始终在暗藏本人，但还是有很多敌人晓得我到底是不是带把的。这个时候，HTTPS就没什么用。

TCP三次握手 四次挥手 QUIC丢掉了 TCP、TLS 的包袱，基于 UDP，并对 TCP、TLS、HTTP/2 的教训加以借鉴、改良，实现了一个平安高效牢靠的 HTTP 通信协议。凭借着 0 RTT 建设连贯、平滑的连贯迁徙、根本打消了队头阻塞、改良的拥塞管制和流量管制等优良的个性，QUIC 在绝大多数场景下取得了比 HTTP/2 更好的成果 建设链接 链接迁徙 队头阻塞/多路复用 拥塞管制Tcp quic HTTPSHTTPS 协定的次要性能根本都依赖于 TLS/SSL 协定，TLS/SSL 的性能实现次要依赖于三类根本算法：散列函数 、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采纳协商的密钥对数据加密，基于散列函数验证信息的完整性, 总起来就是对数据进行加密，建设平安通道，保障数据安全不被拦挡以及进行单方实在身份认证 通信过程浏览器向服务器 443 端口发动申请，会携带本人反对的加密算法 & hash 算法服务器收到申请，抉择加密算法 & hash 算法，下发数字证书给浏览器，这个数字证书能够是从第三方证书机构申请，也能够是自制的如果是证书机构：服务器的经营人员向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否非法，是否领有域名的所有权等 如信息审核通过，CA会向申请者签发认证文件-证书。证书蕴含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、无效工夫、证书序列号等信息的明文，同时蕴含一个签名。 其中签名的产生算法：首先，应用散列函数计算公开的明文信息的信息摘要，而后，采纳 CA的私钥对信息摘要进行加密，密文即签名浏览器收到数字证书之后，开始验证数字证书验证过程：首先浏览器会从内置的证书列表中索引，找到服务器下发证书对应的机构，如果没有找到，此时就会提醒用户该证书是不是由权威机构颁发，是不可信赖的。如果查到了对应的机构，则取出该机构颁发的公钥。用机构的证书公钥解密失去证书的内容和证书签名，内容包含网站的网址、网站的公钥、证书的有效期等。浏览器会先验证证书签名的合法性（采纳雷同的散列函数计算失去信息摘要，而后，利用对应 CA的公钥解密签名数据，比照证书的信息摘要，如果统一，则能够确认证书的合法性，即服务器的公开密钥是值得信赖的）。签名通过后，浏览器验证证书记录的网址是否和以后网址是统一的，不统一会提醒用户。如果网址统一会查看证书有效期，证书过期了也会提醒用户。这些都通过认证时，浏览器就能够平安应用证书中的网站公钥了。浏览器验证数字证书无效，生成一个随机数 R, 并应用网站公钥对 R 加密，而后传给服务器服务器用私钥解密收到的 R，应用 R 用对称加密算法对网页内容加密，并传输给浏览器浏览器以 R 为密钥应用间接约定好的解密算法对网页内容进行解密之后数据申请响应都是用对称加密进行了

http的发展史 在学习网络之前，理解它的历史可能帮忙我明确为何它会倒退为现在这个样子，能让我有探索它的趣味。上面的这张图片就展现了“互联网”诞生至今的倒退历程 http是什么？ HyperTextTransferProtocol 直译为“超文本传输协定”。 1.超文本：指文字、图片、视频、音频等的混合体，比方最相熟的html。 2.传输：http是一个“双向协定”，传输的是申请方和响应方之间的数据，不限度申请方和响应方之间的角色，传递的过程中能够存在任意“中间人”。 3.协定：协是两个或多个参与者之间的交换，议是指对参与者之间的约定和标准。所以，http协定能够了解为作用在计算机之间，应用计算机可能了解的语言确立计算机之间交换通信的标准，以及相干的各种管制和错误处理形式。 所以对于以上的问题能够有这样的总结：http是一个在计算机世界里专门在两点之间传递文字、图片、音频、视频等超文本数据的约定和标准。 与http相干的一些概念 浏览器（web Browser）：浏览器的实质是http中的申请方，应用http协定取得网络上的各种资源。在HTTP协定里，浏览器的角色被称为"User Agent"即用户代理，意思是作为访问者的”代理来发动HTTP申请。下图是一些支流浏览器及其内核。 服务器（web Server)：硬件含意就是物理模式或“云”模式的机器。软件含意的 Web 服务器就是提供 Web 服务的应用程序，通常会运行在硬件含意的服务器上。它利用弱小的硬件能力响应海量的客户端 HTTP 申请，返回动静的信息。常见的web服务器有Apache、Nginx。 CDN（Content Delivery Network）：CDN是为了解决长距离网络拜访速度慢的问题而诞生的一种网络应用服务，全称为“内容散发网络”。CDN最外围的准则是“就近拜访”，应用HTTP协定里的代理和缓存技术，用户在上网的时候不间接拜访原网站，而是拜访离他最近的一个CDN节点，节俭了拜访过程中的工夫老本。（负载平衡，平安防护，边缘计算）。 爬虫（Crawler）：“机器人”模式的用户代理，是一种能够主动拜访Web资源的应用程序。 HTML(Hyper Text Markup Language)：超文本标记语言，用于形容超文本页面，用标签定义图片、文字、排版布局，最终由浏览器渲染。 web Service：由W3C定义的应用服务开发标准，应用client-server主从架构。是一个基于Web（HTTP）的服务架构技术。 WAF：网络应用防火墙，位于Web服务器之前，专门检测http流量，是防护web利用平安的技术。能够阻止SQL注入，跨站脚本攻打，能够齐全集成进Apache或Nginx。 TCP/IP：一系列网络通信协定的统称，其中最外围的是TCP和IP协定。其余的还有UDP，ICMP，ARP等，独特形成一个简单但有档次的协定栈。IP（Internet Protocol）协定次要解决寻址和路由问题，以及如何在两点之间传输数据包。TCP（Transmission Control Protoco）协定位于IP协定之上，意思是“传输控制协议”，基于IP协定提供牢靠的、字节流模式的通信，是HTTP协定实现的根底。互联网上的 HTTP 协定运行在 TCP/IP 上，HTTP 也就能够更精确地称为“HTTP over TCP/IP”。 DNS（Domain Name System）： 域名零碎，用有意义的名字来作为 IP 地址的等价代替。在 DNS 中，“域名”（Domain Name）又称为“主机名”（Host）。域名用“.”分隔成多个单词，级别从左到右逐级升高，最左边的被称为“顶级域名”。但想要应用 TCP/IP 协定来通信依然要应用 IP 地址，所以须要把域名做一个转换，“映射”到它的实在 IP，这就是所谓的“域名解析”。 URI/URL：URI（Uniform Resource Identifier）中文名称是对立资源标识符。DNS 和 IP 地址只是标记了互联网上的主机，URI可能惟一地标记互联网上资源。URI 另一个更罕用的表现形式是 URL（Uniform Resource Locator）， 对立资源定位符，也就是咱们俗称的“网址”，它实际上是 URI 的一个子集，通常不会做严格的辨别。 ...

2021 年 9 月 8 日，字节跳动发表正式开源 CloudWeGo。CloudWeGo 是一套字节跳动外部微服务中间件汇合，具备高性能、强扩展性和稳定性的特点，专一于解决微服务通信与治理的难题，满足不同业务在不同场景的诉求。2022 年 6 月 21 日，Hertz 正式开源。日前，CloudWeGo 团队正式开源字节跳动最大的 HTTP 框架 Hertz。Hertz 在公布之后失去了大量用户的关注，开源四个月以来，Hertz 曾经播种了 2K+ star。有很多用户本人进行了测试，感激社区对咱们的关注和反对。 本文旨在分享开发者在压测 Hertz 时须要理解的场景和技术问题。这些倡议有助于用户更好地联合实在 HTTP 场景对 Hertz 进行调优，使之更贴合业务须要、施展最佳性能。用户也能够参考官网提供的压测我的项目 hertz-benchmark 理解更多细节。 hertz-benchmark: https://github.com/cloudwego/... 01 微服务 HTTP 场景的特点Hertz 诞生于字节跳动大规模微服务架构实际，面向的场景天然是微服务场景，因而上面会先介绍微服务 HTTP 场景的特点，不便开发者深刻了解 Hertz 在其中的设计思考。 HTTP 通信模型微服务间的通信通常以 Ping-Pong 模型为主，除了惯例的吞吐性能指标外，每次 HTTP 的均匀时延也是开发者须要思考的点。吞吐达到瓶颈时能够通过减少机器疾速解决，但对用户应用体验有显著影响的时延却没有那么容易升高。在微服务场景下，一次调用往往须要多个微服务合作实现，即便每个节点提早很低，最终汇聚到链路上的时延也会被放大，因而微服务场景下时延指标是开发者更应该关注的点。Hertz 在保障吞吐的前提下，也针对时延做了肯定优化。 长短连贯应用因为 TCP 连贯首次建设时须要三次握手，如果每个申请都建设新连贯，这部分的开销是十分大的。因而对于时延敏感型服务，尽量应用长连贯实现申请。在 HTTP 1.1 中，长连贯也是默认的选项。然而没有银弹，维持连贯也须要耗费资源，长连贯的程度扩大能力也不如短连贯。因而，在某些场景下并不适宜应用长连贯，比方定时拉取配置的场景，在这个场景下，建连时延对配置影响并不大，且当配置核心负载过高时，心愿可能不便的进行程度扩容，这时短连贯可能是一个更好的抉择。 包体积大小一个服务的包大小取决于理论的业务场景。HTTP 场景的数据能够放在 query、path、header、body 等中央，不同地位对解析造成的影响也不一样。HTTP 的 header 是标识符协定，在没有找到特定的标识符之前，框架并不知道 header 还有多少，因而框架须要收到全副的 header 后才可能解析实现，对框架的内存模型不很敌对。Hertz 也针对 header 解析做了非凡的优化，调配足够的 buffer 空间给 header，缩小 header 解决时跨包拷贝的开销。 ...

引言在《图解HTTP》的读书笔记《图解HTTP》- HTTP协定历史倒退（重点） 当中介绍了一部分对于HTTP/2的内容，然而内容比拟简短没有过多深刻，本文对于HTTP/2 协定做一个更深刻的介绍。 概览HTTP1.X 有两个次要的毛病：平安有余和性能不高。 所谓平安有余，是指HTTP1.X 大部分时候应用了明文传输，所以很多时候黑客能够通过抓包报文的形式对于网络数据进行监控和尝试破解，为了平安传输数据，HTTP通常和TLS组合实现网络安全连贯。 性能不高则指的是HTTP在申请传输中会传输大量的反复字段，Body的数据能够通过GZIP进行压缩。这达到了能够勉强承受传输效率，然而Header头部字段仍旧十分臃肿和低效，并且HTTP1.X 后续也没无效的头部压缩伎俩，HTTP/2 借用了哈夫曼编码对于Header进行高效压缩，进步传输效率。 除了下面的问题，HTTP1.X中最大的问题是队头阻塞，HTTP1.X中浏览器对于同一域名的并发连贯拜访此时是无限的，所以经常会导致只有个位数的连贯能够失常工作，后续的连贯都会被阻塞。 HTTP/2 解决队头阻塞是以 HTTP1.X 管道化的为根底拓展，它应用了二进制流和帧概念解决应用层队头阻塞。应用层的阻塞被解决便是实现流并发传输。 为了管制资源的资源的获取程序，HTTP在并发传输的根底上实现申请优先级以及流量管制，流的流量管制是思考接管方是否具备承受能力。 在发送方存在WINDOWS流量窗口，而接管方能够通过一个叫做WINDOW_UPDATE帧限度发送方的传输长度。要了解HTTP/2的细节须要有一个宏观的概念：为了提高效率，HTTP/2整体都在向着TCP协定贴近。 以上就是对于HTTP/2降级的含糊了解，HTTP/2 的改良从整体上分为上面几个局部： 兼容HTTP1.X应用层队头阻塞解决并发传输多路复用二进制帧服务器推送HPACK/头部压缩申请优先级补充 连贯前言流和管道化关系申请头字段束缚兼容HTTP1.XHTTP和TLS协定一样背着微小的历史包袱，所以不能在结构上做出过多的改变，HTTP/2为了进行推广也必须要进行前后兼容，而兼容HTTP1.X 则疏导出上面三个点： HTTP协定头平滑过渡应用层协定扭转根本传输格局的保障HTTP协定头平滑过渡 所谓的平滑过渡指的是协定头的辨认仍然是 HTTP结尾，不论是HTTP1 还是 HTTP/2，甚至是HTTP3，都将会沿用http结尾的协定名进行向后兼容。 应用层协定扭转 HTTP/2只扭转了应用层并没有扭转TCP层和IP层，所以数据仍然是通过TCP报文的形式进行传输，通样通过TCP握手和HTTP握手实现。 根本传输格局的保障 HTTP1.X中的申请报文格式如下，联合来说申请报文能够总结为上面的格局： 申请行申请首部字段和其余字段空行申请负载 HTTP 尽管把外部的格局大变样，然而申请报文的构造总体是没有变的。 推广平安HTTP/2是“事实上的平安协定”，HTTP/2尽管并没有强制应用SSL平安传输，然而许多浏支流浏览器曾经不反对非HTTPS进行HTTP2 申请，同时能够发现很多实现了HTTP/2的网站根本都是都是具备HTTPS平安传输条件的。 因为HTTP/2要比TLS1.3早出几年，HTTP/2推广加密版本的 HTTP/2 在平安方面做了强化，要求上层的通信协议必须是TLS1.2 以上，并且此时TLS1.2很多加密算法曾经被证实存在安全隐患（比方DES、RC4、CBC、SHA-1不可用），所以应用HTTP/2被要求保障前向平安，更像是TLS1.25。 因为TLS1.3要比HTTP/2要晚几年才出台，而HTTP/2呈现的时候TLS很多加密套件早曾经没法应用了，所以HTTP/2应用的TLS1.2加密套件是带椭圆曲线函数的TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。HTTP/2协定还对加密和不加密的报文进行划分，HTTP/2 定义了字符串标识标识明文和非明文传输，“h2”示意加密的 HTTP/2，“h2c”示意明文的 HTTP/2，这个c示意"clear text"。 协定栈变动从HTTP1.X 到HTTPS以及HTTP/2的协定栈变动图能够看到整个应用层协定尽管构造上没有过多调整，然而内容呈现了翻天覆地的变动，实现细节也更加简单。 尽管HTTP/2的“语法”简单了很多，然而“语义”自身是没有变动的，用HTTP1.X 的一些思路形象了解HTTP/2的构造定义是实用的。 二进制帧（Stream）二进制帧是HTTP/2的“语法”变动，HTTP/2的传输格局由明文转为了二进制格局， 属于向 TCP/IP 协定“聚拢”，能够通过位运算提高效率。 二进制的格局尽管对于人浏览了解不是很敌对，然而对于机器来说却刚好相同，实际上二进制传输反倒要比明文传输省事多了，因为二进制只有0和1相对不会造成解析上的歧义，也不会因为编码问题须要额定转译。 二进制帧保留Header+Body传输构造，然而打散了外部的传输格局，把内容拆分为二进制帧的格局，HTTP/2把报文的根本传输单位叫做帧，而帧分为两个大类 HEADERS（首部） 和 DATA（音讯负载），一个音讯划分为两类帧传输同时采纳二进制编码。 这种做法相似Chunked化整数据的形式，把Header+body等同的帧数据，同时外部通过类型判断进行标记。 这里能够举个简略例子，比方常见的状态码 200，用文本数据传输须要3个字节（二进制：00110010 00110000 00110000），而用HTTP/2的二进制只须要1个字节（10001000） 二进制分帧构造HTTP/2的数据传输根本单位（最小单位）是帧，帧构造如下： 留神这里的单位是bit不是byte，头部实际上占用的字节数非常少，一共加起来也就9个字节大小。其中3个字节的长度示意长度，帧长度前面示意帧类型，HTTP/2定义了多大10种类型帧，次要分为数据帧和管制帧： ...

技术文档HTTP状态码有哪些？别离代表什么？ 简略版： 100-continue：持续，个别在发送post申请时，已发送http header之后服务器端将返回此信息示意确认，之后发送具体参数信息。200-OK：失常返回信息201-created：申请胜利并且服务器创立了新的资源202-Accepted：服务器已承受申请，但尚未解决301-Moved Permanently：申请的网页曾经永恒挪动到新的地位302-Found：临时性重定向303-See Other：临时性重定向，且总是应用GET申请新的URI304-Not Modified：自从上次申请后，申请的网页未修改过400-Bad Request：服务器无奈了解申请的格局，客户端不该当尝试再次应用雷同的内容发动申请401-Unauthorized：申请未受权403-Forbidden：禁止拜访404-Not Found：找不到如何与URI相匹配的资源500-Internal Server Error：最常见的服务器端谬误503-Server Unavailable：服务器端临时无奈解决申请（可能是过载或保护）完整版： 1**（信息类）：示意接管到申请并且持续解决100——客户必须持续发出请求101——客户要求服务器依据申请转换HTML协定版本2**（响应胜利）：示意动作被胜利接管、了解和承受200——表明该申请被胜利地实现，所申请的资源发送回客户端201——提醒晓得新文件的URL202——承受和解决、但解决未实现203——返回信息不确定或不残缺204——申请收到，但返回信息为空205——服务器实现了申请，用户代理必须复位以后曾经浏览过的文件206——服务器曾经实现了局部用户的GET申请3**（重定向类）：为了实现指定的动作，必须承受进一步解决300——申请的资源可在多处失去301——本网页被永久性转移到另一个URL302——申请的网页被转移到一个新的地址，但客户拜访仍持续通过原始URL地址，重定向，新的URL会在response中的Location中返回，浏览器将会应用新的URL收回新的request。303——倡议客户拜访其余URL或拜访形式304——自从上次申请后，申请的网页未修改过，服务器返回此响应时，不会返回网页内容，代表上次的文档曾经被缓存，还能够持续应用。305——申请的资源必须从服务器指定的地址失去306——前一版本HTTP中应用的代码，现行版本中不再应用307——申明申请的资源临时性删除4**（客户端谬误类）：申请蕴含谬误语法或不能正确执行400——客户端申请有语法错误，不能被服务器所了解401——申请未经受权，这个状态码必须和WWW-Authenticate报头域一起应用HTTP 401.1——未受权：登录失败HTTP 401.2——未受权：服务器配置问题导致登录失败HTTP 401.3——ACL 禁止拜访资源HTTP 401.4——未受权：受权被筛选器回绝HTTP 401.5——未受权：ISAPI或CGI受权失败402——保留无效ChargeTo头响应403——禁止拜访，服务器收到申请，然而回绝提供服务HTTP 403.1——禁止拜访：禁止可执行拜访HTTP 403.2——禁止拜访：禁止读拜访HTTP 403.3——禁止拜访：禁止写访问HTTP 403.4——禁止拜访：要求SSLHTTP 403.5——禁止拜访：要求SSL 128HTTP 403.6——禁止拜访：IP地址被回绝HTTP 403.7——禁止拜访：要求客户证书HTTP 403.8——禁止拜访：禁止站点拜访HTTP 403.9——禁止拜访：连贯的用户过多HTTP 403.10——禁止拜访：配置有效HTTP 403.11——禁止拜访：明码更改HTTP 403.12——禁止拜访：映射器回绝拜访HTTP 403.13——禁止拜访：客户证书已被撤消HTTP 403.15——禁止拜访：客户拜访许可过多HTTP 403.16——禁止拜访：客户证书不可信或者有效HTTP 403.17——禁止拜访：客户证书曾经到期或者尚未失效404——一个404谬误表明可连贯服务器，但服务器无奈获得所申请的网页，申请资源不存在。405——用户在Request-Line字段定义的办法不予许406——依据用户发送的Accept头，申请资源不可拜访407——相似401，用户必须首先在代理服务器上失去受权408——客户端没有在用户指定的工夫内实现申请409——对以后资源状态，申请不能实现410——服务器上不再有此资源，且无进一步的参考地址411——服务器回绝用户定义的Content-Length属性申请412——一个或多个申请头字段在以后申请中谬误413——申请的资源大于服务器容许的大小414——申请的资源URL长于服务器容许的长度415——申请的资源不反对申请我的项目格局416——申请中蕴含Range申请头字段，在以后申请资源范畴内没有Range批示值，申请也不蕴含If-Rane申请头字段417——服务器不满足申请Expect头字段指定的期望值，如果是代理服务器，可能是下一级服务器不能满足申请。5**（服务端谬误类）：服务器不能正确执行一个正确的申请HTTP 500——服务器遇到谬误，无奈实现申请HTTP 500.100——外部服务器谬误——ASP谬误HTTP 500.11——服务器敞开HTTP 500.12——应用程序重新启动HTTP 500.13——服务器太忙HTTP 500.14——应用程序有效HTTP 500.15——不容许申请global.asaError 501——未实现HTTP 502——网关谬误HTTP 503——因为超载或停机保护，服务器目前无奈应用，一段时间后可能恢复正常一个页面从输出URL到页面加载显示实现，这个过程产生了什么？（流程越具体越好） 从URL标准、HTTP协定、DNS、CDN、数据库查问到浏览器解析、CSS规定构建、layout、paint、onload/domready、JS执行、JS API绑定等1、浏览器会开启一个线程来解决这个申请，对URL分析判断如果是HTTP协定就依照Web形式来解决；2、调用浏览器内核中的对应办法，比方webview 中的loadUrl办法；3、通过DNS解析获取网址的IP地址，设置UA等信息收回第二个GET申请；4、忘性HTTP协定会话，客户端发送报头（申请报头）；5、进入到web服务器上的Web Server，如Accept、Tomcat、Node.js等服务器；6、进入部署好的后端利用，如PHP、Java、JavaScript、python等，找到对应的申请解决；7、解决完结反馈报头，此处如果浏览器拜访过，缓存上有对应资源，会与服务器最初批改工夫比照，统一则返回304；8、浏览器开始下载HTML文档（响应报头，状态码200），同时是应用缓存；9、文档树建设，依据标记申请所须要指定MIME类型的文件（比方css、js），同时设置了cookie；10、页面开始渲染DOM，JS依据DOM API操作DOM，执行事件绑定等，页面显示实现。浏览器把申请的URL交给DNS域名解析，找到实在IP，向服务器发动申请；服务器交给后盾解决实现后返回数据，浏览器接管文件；浏览器对加载到的资源进行语法解析，建设相应的外部数据结构；载入解析好的资源文件，渲染页面显示内容。从输出URL(或跳转页面)到获取HTML的具体过程 加载一个资源的过程 浏览器依据DNS服务器失去域名的IP地址向这个IP的机器发送HTTP申请服务器收到、解决并返回HTTP申请浏览器失去返回内容安全性 XSS跨站申请攻打XSRF跨站申请伪造在博客写文章，同时偷偷插入一段<script-攻打代码中，获取cookie，发送到本人的服务器公布博客，有人查看博客会把查看者的cookie发送到攻击者的服务器

日前，字节跳动技术社区 ByteTech 举办的第七期字节跳动技术沙龙圆满闭幕，本期沙龙以《字节高性能开源微服务框架：CloudWeGo》为主题。在沙龙中，字节跳动字节跳动基础架构服务框架资深研发工程师高文举，跟大家分享了《大规模企业级 HTTP 框架的设计和实际》，本文依据分享整顿而成。 本文将从以下五个方面介绍 CloudWeGo 大规模企业级 HTTP 框架 Hertz： 1. 字节跳动外部 Go HTTP 框架的变迁；2. 企业级 HTTP 框架的设计考量和落地思路；3. Hertz 的外围特点；4. 将来布局和挑战； 总结。 字节跳动外部 Go HTTP 框架的变迁在正式开始介绍第一局部的内容之前，先给大家展现一组关键词。2020 年初 Hertz 立项，2020 年 10 月，Hertz 公布第一个可用版本。2022 年 6 月，Hertz 正式开源。截至目前，Hertz 在字节外部曾经撑持超过 1.4 万个业务服务，日峰值 QPS 超过 5000 万。 Hertz 不仅反对业务服务，同时还会横向反对字节外部的各种根底组件，包含但不限于字节跳动服务网格管制面、公司级别压测平台以及 FaaS，还包含各种业务网关等等。Hertz 的高性能和极强的稳定性能够撑持业务复杂多变的场景。在公司外部 Hertz 接替了大量基于 Gin 框架开发的存量服务，大幅度降低了业务资源应用老本以及服务延时，助力公司层面的降本增效。 上面咱们能够从 Hertz 呈现的背景以及 Hertz 的设计指标和思路领会到，Hertz 的呈现绝不是偶尔。 基于 Gin 封装家喻户晓，字节外部应用 Golang 比拟早，在大概 2014 年左右，公司就曾经开始尝试做一些 Golang 业务的转型。2016 年，咱们基于已开源的 Golang HTTP 框架 Gin 框架，封装了 Ginex，这是 Ginex 刚开始呈现的期间。 ...

平时咱们关上网页，比方购物网站某宝。都是点一下列表商品，跳转一下网页就到了商品详情。 从HTTP协定的角度来看，就是点一下网页上的某个按钮，前端发一次HTTP申请，网站返回一次HTTP响应。 这种由客户端被动申请，服务器响应的形式也满足大部分网页的性能场景。 但有没有发现，这种状况下，服务器素来就不会被动给客户端发一次音讯。 就像你喜爱的女生从来不会被动找你一样。 但如果当初，你在刷网页的时候右下角忽然弹出一个小广告，提醒你【一个人在家偷偷能力玩哦】。 求知，好学，怠惰，这些刻在你DNA里的货色都动起来了。 你点开后发现。 长相平平无奇的古某提醒你"道士9条狗，全服横着走"。 影帝某辉老师跟你说"系兄弟就来砍我"。 来都来了，你就选了个角色进到了游戏界面里。 这时候，上来就是一个小怪，从远处走来，而后疯狂拿木棒子抽你。 你全程没点任何一次鼠标。服务器就主动将怪物的挪动数据和攻打数据源源不断发给你了。 这….太暖心了。 打动之余，问题就来了， 像这种看起来服务器被动发消息给客户端的场景，是怎么做到的？ 在真正答复这个问题之前，咱们先来聊下一些相干的常识背景。 应用HTTP一直轮询其实问题的痛点在于，怎么样能力在用户不做任何操作的状况下，网页能收到音讯并产生变更。 最常见的解决方案是，网页的前端代码里一直定时发HTTP申请到服务器，服务器收到申请后给客户端响应音讯。 这其实时一种伪服务器推的模式。 它其实并不是服务器被动发消息到客户端，而是客户端本人一直偷偷申请服务器，只是用户无感知而已。 用这种形式的场景也有很多，最常见的就是扫码登录。 比方某信公众号平台，登录页面二维码呈现之后，前端网页基本不晓得用户扫没扫，于是一直去向后端服务器询问，看有没有人扫过这个码。而且是以大略1到2秒的距离去一直发出请求，这样能够保障用户在扫码后能在1到2s内失去及时的反馈，不至于等太久。 但这样，会有两个比拟显著的问题 当你关上F12页面时，你会发现满屏的HTTP申请。尽管很小，但这其实也耗费带宽，同时也会减少上游服务器的累赘。最坏状况下，用户在扫码后，须要等个1~2s，正好才触发下一次http申请，而后才跳转页面，用户会感到显著的卡顿。应用起来的体验就是，二维码呈现后，手机扫一扫，而后在手机上点个确认，这时候卡顿等个1~2s，页面才跳转。 那么问题又来了，有没有更好的解决方案？ 有，而且实现起来老本还非常低。 长轮询咱们晓得，HTTP申请收回后，个别会给服务器留肯定的工夫做响应，比方3s，规定工夫内没返回，就认为是超时。 如果咱们的HTTP申请将超时设置的很大，比方30s，在这30s内只有服务器收到了扫码申请，就立马返回给客户端网页。如果超时，那就立马发动下一次申请。 这样就缩小了HTTP申请的个数，并且因为大部分状况下，用户都会在某个30s的区间内做扫码操作，所以响应也是及时的。 比方，某度云网盘就是这么干的。所以你会发现一扫码，手机上点个确认，电脑端网页就秒跳转，体验很好。 真两全其美。 像这种发动一个申请，在较长时间内期待服务器响应的机制，就是所谓的长训轮机制。咱们罕用的音讯队列RocketMQ中，消费者去取数据时，也用到了这种形式。 像这种，在用户不感知的状况下，服务器将数据推送给浏览器的技术，就是所谓的服务器推送技术，它还有个毫不沾边的英文名，comet技术，大家听过就好。 下面提到的两种解决方案，实质上，其实还是客户端被动去取数据。 对于像扫码登录这样的简略场景还能用用。 但如果是网页游戏呢，游戏个别会有大量的数据须要从服务器被动推送到客户端。 这就得说下websocket了。 websocket是什么咱们晓得TCP连贯的两端，同一时间里，单方都能够被动向对方发送数据。这就是所谓的全双工。 而当初应用最宽泛的HTTP1.1，也是基于TCP协定的，同一时间里，客户端和服务器只能有一方被动发数据，这就是所谓的半双工。 也就是说，好好的全双工TCP，被HTTP用成了半双工。 为什么？ 这是因为HTTP协定设计之初，思考的是看看网页文本的场景，能做到客户端发动申请再由服务器响应，就够了，基本就没思考网页游戏这种，客户端和服务器之间都要相互被动发大量数据的场景。 所以为了更好的反对这样的场景，咱们须要另外一个基于TCP的新协定。 于是新的应用层协定websocket就被设计进去了。 大家别被这个名字给带偏了。尽管名字带了个socket，但其实socket和websocket之间，就跟雷峰和雷峰塔一样，二者靠近毫无关系。 怎么建设websocket连贯咱们平时刷网页，个别都是在浏览器上刷的，一会刷刷图文，这时候用的是HTTP协定，一会关上网页游戏，这时候就得切换成咱们新介绍的websocket协定。 为了兼容这些应用场景。浏览器在TCP三次握手建设连贯之后，都对立应用HTTP协定先进行一次通信。 如果此时是一般的HTTP申请，那后续单方就还是老样子持续用一般HTTP协定进行交互，这点没啥疑难。如果这时候是想建设websocket连贯，就会在HTTP申请里带上一些非凡的header头。Connection: UpgradeUpgrade: websocketSec-WebSocket-Key: T2a6wZlAwhgQNqruZ2YUyg==\r\n这些header头的意思是，浏览器想降级协定（Connection: Upgrade），并且想升级成websocket协定（Upgrade: websocket）。 同时带上一段随机生成的base64码（Sec-WebSocket-Key），发给服务器。 如果服务器正好反对升级成websocket协定。就会走websocket握手流程，同时依据客户端生成的base64码，用某个公开的算法变成另一段字符串，放在HTTP响应的 Sec-WebSocket-Accept 头里，同时带上101状态码，发回给浏览器。 HTTP/1.1 101 Switching Protocols\r\nSec-WebSocket-Accept: iBJKv/ALIW2DobfoA4dmr3JHBCY=\r\nUpgrade: websocket\r\nConnection: Upgrade\r\nhttp状态码=200（失常响应）的状况，大家见得多了。101的确不常见，它其实是指协定切换。 之后，浏览器也用同样的公开算法将base64码转成另一段字符串，如果这段字符串跟服务器传回来的字符串统一，那验证通过。 就这样经验了一来一回两次HTTP握手，websocket就建设实现了，后续单方就能够应用webscoket的数据格式进行通信了。 websocket抓包咱们能够用wireshark抓个包，理论看下数据包的状况。 ...

HTTP - HTTPS优化引言本节介绍额HTTPS优化是一个不小的话题，对于优化的探讨是在其余软硬件合理配置的前提下进行讨，对于HTTPS本，咱们经常会想它必定要比HTTP要慢，实际上一个优化良好的HTTPS有时候要比HTTP要快很多。 本节针对于TLS1.3以及TLS1.2的优化点存在一些差异，然而整体上更倡议有条件就上TLS1.3，在整个TLS优化上的收益根本是最高的。 上面咱们先剖析一下相干的优化点。 剖析优化点咱们依据TLS1.2的流程剖析优化点，TLS1.2因为各种起因存在许多待优化的内容，从交互流程下面很容易看出一些计算耗费的问题： 证书校验；密钥计算（次要是服务端改良）；计算会话密钥；屡次数据往返；密钥替换算法的抉择； 优化点依据下面的简略探讨，咱们整顿出上面的次要优化点： 2TT 对称密钥协商工夫硬件优化 AES- NI的 CPUSSL 加速卡SSL 减速服务器软件降级 Linux降级OpenSSL降级和破绽修复协定优化 尽量降级到TLS1.3应用 ECDHE 椭圆曲线函数，前向平安，速度快。会话重用 Session Id => TLS1.2 传统会话重用机制，然而对于服务端的累赘很大。Session Ticket => TLS 1.2 呈现给予Session Id 一种革新降级，然而实际上有很大的安全隐患，那就是Session Ticket的用来解密的会话密钥w文件是固定的，推特利用了发牌器以及 tmfps 实现了会话密钥的定期轮换，以及会话密钥自身的有效期安全控制。（“Session Ticket”计划须要应用一个固定的密钥文件（ticket_key）来加密 Ticket，为了避免密钥被破解，保障“前向平安”，密钥文件须要定期轮换，比方设置为一小时或者一天）预共享密钥（PSK），PSK真正实现了0-RTT，通过“early data” + key_share传输PSK，间接实现0-RTT握手，无需CA、CV、以及证书校验的过程。然而PSK的形式存在重放攻打的问题，不是很平安，所以理论应用的并不多。硬件优化硬件优化说白了就是充钱，只不过充钱要充对中央，须要留神HTTPS 协定是计算密集型，而不是 I/O 密集型，所以盯着硬盘和网卡降级是没有意义的，所以这时候应用自带AES的CPU就显得非常重要了，反对 AES-NI 个性的 CPU能够在连贯握手的时候利用CPU指令优化AES算法，这样也相当于减速了整个加密传输的过程。 除了CPU之外的其余办法是SSL加速卡和SSL减速服务器。“SSL 加速卡”作用是在加解密时调用它的 API，让专门的硬件来做非对称加解密，分担 CPU 的计算压力，然而加速卡存在缺点，降级慢、反对算法无限，不能灵便定制解决方案等问题。 于是这时候就要用到SSL服务器了，利用SSL服务器齐全累赘TLS协定加密和解密过程中的计算耗费，因为是独立服务器，也要比单纯的SSL加速卡要更加成熟和欠缺。但让部署SSL减速服务的硬件老本会显著回升。 软件降级软件降级有时候能带来不错的收益，比方Linux 内核由 2.x 降级到 4.x，把 Nginx 由 1.6 降级到 1.16，把 OpenSSL 由 1.0.1 降级到 1.1.0/1.1.1。这些降级不仅能够解决一些被人熟知的破绽，这些软件被成千上万的团队应用，通过各种考验和利用，自身非常成熟，降级也不会造成微小的影响。 协定优化当初大多数的反对HTTPS服务器根本都不会再用RSA算法了，因为RSA 密钥替换算法的 TLS 握手过程，不仅慢，而且安全性也不高，会呈现前向安全性问题，同时还须要消耗2-RTT的往返工夫，这个工夫消耗也是TLS1.2的次要性能瓶颈。而以更为高效和前向平安椭圆曲线函数显然是更适合的抉择，并且在TLS 1.3中把RSA相干等一系列不平安的算法给间接干掉了。 ...

引言在HTTP - HTTPS（TLS1.2）中，咱们介绍了目前世界支流的TLS1.2协定的相干知识点，文中从HTTP的缺点、SSL的历史、信息加密的次要伎俩、数字证书、以及最为要害的TLS1.2交互过程介绍了现今HTTPS的要害局部内容。 TLS1.3在曾经2018年退场，这一节咱们来看看依据TLS1.3协定整体大抵讲了什么内容。 因为TLS1.2曾经做的比较完善，TLS1.3 的次要改良集体认为要害分为三个次要改良指标：兼容、平安与性能。 工夫线 TLS 1.3 改良点兼容性TLS1.2 倒退了很多年了，基本上少数网络设备对于这个版本的协定产生了依赖性，如果间接用TLS1.3的版本协定替换掉TLS1.2，大量的代理服务器、网关都无奈正确处理，TLS1.2 存在微小的历史包袱。 TLS1.3 显然是没法撼动TLS1.2这个“老皇帝”的，这要怎么办呢？所以TLS1.3想到了一招“垂帘听政”，既然没法替换掉，那就是借用“TLS1.2”的名号进行传输数据，也就是所谓的“假装”。 那么该怎么辨别 TLS1.2 和 TLS1.3 呢？这时候就要用到扩大协定（Extension Protocol），裁减协定有点相似“追加条款”，只反对TLS1.2的服务器，当无奈辨认扩大协定而被疏忽进化为TLS1.2握手，反之则认为能够进行TLS1.3协定握手。留神这里的进化还不止那么简略，TLS1.3 的进化只反对TLS1.2，不反对TLS1.2以下任何版本，所以这一招还偷偷把一些老古董请上来。 TLS1.3的改良是形式记录头部的Version 字段“固定不变”，以及在进行第一步Hello交互之后须要立即发送supported_versions的音讯示意本人反对 TLS1.3协定，相似信号通知对方本人理论的 TLS 的版本号，也是新旧协定的次要分水岭。 TLS1.3在握手的时候会呈现上面的变动： Handshake Protocol: Client HelloVersion: TLS 1.2 (0x0303)Extension: supported_versions (len=11)Supported Version: TLS 1.3 (0x0304)Supported Version: TLS 1.2 (0x0303)平安强化：“瘦身”TLS1.2 尽管在平安方面曾经显得非常欠缺了，然而通过多年的考验还是发现不少的问题。所以 TLS1.3 次要是给TLS1.2遗留问题进行修复，比如说进行了上面的调整： 伪随机数函数由 PRF 降级为 HKDF（HMAC-based Extract-and-Expand Key Derivation Function）；明确禁止在记录协定里应用压缩，因为应用压缩被是存在破绽的并且有可能被黑客用非凡算法破解；（详情参考文章开端“TLS1.2 攻打伎俩”）破除了 RC4、DES 对称加密算法；破除了 ECB、CBC 等传统分组模式；破除了 MD5、SHA1、SHA-224 摘要算法；破除了 RSA、DH 密钥替换算法和许多命名曲线;ServerHello 之后的所有握手音讯采取了加密操作，可见明文大大减少;DSA 证书不再容许在 TLS 1.3 中应用;下面这些点说是强化。更像是“瘦身”，因为废除了很多被证实不平安的算法。 ...

HTTP SecurityHTTP CSP3指标缩小内容注入攻打的危险，包含： 1） 嵌入文档的资源（worker/iframe） 2）内联脚本 3）动静脚本（eval） 4) 内联款式提供能力管制嵌入资源能够应用哪些源（origin）提供一个report机制Directives指令相干执行查看的机会： Pre-request checkPost-request checkInline checkInitializationPre-navigation checkNavigation response check能够配置的Source List关键字none和self(只匹配以后URL的Origin)URL（例如: https://example.com/path/to/f...，特定的文件；https://example.com/，Origin下所有的资源）协定（例如: https:）域名（例如：example.com，*.example.com）Nonces （例如：nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA，匹配页面上特定的元素例如: <script nonce=“ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA” …></script>）Digests （例如：sha256-abcd，匹配页面上特定的元素: 例如<script integrity=“sha256-abcd”….><script>）Policy Delivery能够在HTTP返回头Content-Security-Policy申明也能够在页面上的meta元素http-equiv属性上申明Content-Security-Policy-Report-Only响应头能够容许开发者收集页面上违反policy的报告 然而这个响应头是不反对在meta标签上配置的 反对meta标签配置例如： <meta http-equiv="Content-Security-Policy" content="script-src 'self'">然而Content-Security-Policy-Report-Only，report-uri, frame-ancestors，sandbox也是不反对 如何捕捉和上报违规行为当产生违规行为时，就会在element或者windows触发一个SecurityPolicyViolationEvent事件，js能够通过以下代码来进行捕捉 if ('SecurityPolicyViolationEvent' in window) { // Check browser support window.addEventListener('securitypolicyviolation', function(e) { console.log( e.violatedDirective, e.originalPolicy ); }); }所有指令Fetch Directiveschild-src 能够管制iframe，frame和worker的申请加载connect-src 管制fetch()，xhr, eventsource, beacon, a标签， websocket的申请加载default-src能够作为其余fetch directive的默认值font-src 能够管制字体资源的申请加载frame-src 能够管制ifream, frame的申请加载Img-src 管制图片的申请加载manifest-src 管制manifest的申请加载 <link rel="manifest" href="https://example.org/manifest">media-src 管制video，audio还有track等申请加载 <audio src="https://example.org/audio"></audio> <video src="https://example.org/video"> <track kind="subtitles" src="https://example.org/subtitles"> </video>object-src 管制embed，object的申请加载prefetch-src ...

Cache类型private cache意味着该缓存不会与其余用户共享 share cacheProxy cache 就是两头代理服务器的缓存，然而因为https的风行，这些代理服务器基本上只能转发申请Managed cached 就是源服务器配置的缓存：nginx，cdn，service worker什么样申请响应时能够被缓存的响应的状态码是1xx, 2xx，3xx, 4xx，5xx范畴内没有呈现no-store指令响应含有Expire字段或者以下的指令：public，private，max-age，s-maxage，immutable等缓存响应的key个别应用申请办法 + 申请的URI作为缓存的key，然而能够应用vary字段，增加响应头作为key的一部分例如：Vary: Accept-Language Freshness只有响应的age不超过它的freshness lifetime 就认为是是“陈腐的”，否则就会认为曾经过期 freshness lifetime 是指响应从服务器产生到它的过期工夫这段时间范畴 explicit expiration time 是指响应头蕴含Expires字段或者max-age指令 age 是指该响应从服务产生后所过来的工夫 浏览器也能够应用max-age或者min-fresh申请指令来倡议服务器返对应的响应（例如浏览器强制刷新的时候就会带上max-age=0） Freshness Lifetime （Freshness生命周期计算）如果cache是共享的，而且响应头也蕴含s-maxage，则应用这个值如果响应头蕴含max-age，则应用这个值如果响应头蕴含Expires，则应用这个字段减去Date字段（如果Date字段不存在，则应用接管响应的工夫）否则如果在响应头没有明确的过期工夫，则会利用一种启发式的Freshness Lifetime去计算如果响应头呈现多个Expires或者多个Cache-Control: max-age ，则能够应用第一个字段的值或者认为这个响应曾经stale（行为未定义，要依据浏览器理论行为参考），如果缓存指令呈现抵触，例如（max-age和no-cache同时呈现）则只会利用最严格的那个指令；如果max-age是有效的值，则也会认为该响应是stale的 Calculating Heuristic Freshness （启发式计算Freshness）次要起因因为服务器可能不会提供明确的过期工夫（没有Expires和max-age），所以这个时候缓存本人要给文件计算一个过期工夫，例如应用其余字段Last-Modified工夫辅助计算，然而这里不会给出一个固定的算法，要浏览器本人定义。然而还是给出一个参考：（ Last-Modified - Date）* 10%（能够认为如果隔了这么一段时间才批改，大略下次批改也会在这段时间之内，所以生命周期也在这个工夫范畴内） Age计算age_value 响应头Age字段，如果没有则认为是0date_value 响应头Date字段now 以后工夫request_time 申请工夫response_time 响应工夫 计算形式次要有两种 apparent_age ， response_time减去date_value，如果浏览器工夫是跟服务器工夫同步的应该是比拟精确（然而不太可能） apparent_age = max(0, response_time - date_value);corrected_age_value (只有反对http1.1以上的都应用这个计算形式)response_delay = response_time - request_time; corrected_age_value = age_value + response_delay;而后corrected_age_value 还能够被用作corrected_initial_age，然而还有一种状况就是返回头没有Age字段的时候（age_value则视为0参加corrected_age_value计算），corrected_initial_age能够上面激进的形式计算，别离统计apparent_age和corrected_age_value，再求最大值：corrected_initial_age = max(apparent_age, corrected_age_value); ...

HTTP 缓存技术缓存技术呈现在HTTP1.1当中，目标是尽可能的缩小对于服务器进行申请。为了实现缓存技术，HTTP设计者在头部字段减少针对缓存的头部字段。HTTP 缓存有两种形式，强制缓存和协商缓存。 意识缓存介绍具体的缓存技术之前，咱们先来认识一下HTTP中的缓存特点。 留神缓存只对获取文件无效，从服务器上拿到文件而后放入本地缓存，下次再获取则从本地缓存区获取文件，这样能够加重服务器压力。 缓存技术在HTTP中的体现是通过几个申请字段的配合，依照肯定的判断流程管制。HTTP1.1次要通过上面三个申请头部信息断定缓存有效性： Cache-Control：服务器能够返回此字段指定浏览器和两头缓存应该存活多久。ETag：浏览器缓存过期的时候，通过Etag令牌查看文件是否呈现扭转。Etag 是非凡算法计算的惟一哈希值。Last-Modified：和Etag用处雷同，然而它是基于工夫的策略查看是否更改。这三个字段根本囊括大部分HTTP缓存技术的利用场景。 缓存地位缓存地位通常存在上面几种： Service WorkMemory CacheDisk Cache（罕用）Push CacheService Work通常运行在浏览器的后盾，次要性能是实现缓存，应用此组件须要申请协定为HTTPS，因为Service Work 自身会拦挡申请，须要 HTTPS保障平安能力应用。 Memory Cache内存中的缓存，次要是以后页面曾经捕捉的资源。比方图片，脚本等，这种形式要比Disk Cache 要快上十分多，然而留神这个缓存寿命十分短，一旦敞开Tab，内存缓存会随着页面的敞开立马开释。 内存缓存中有一块重要的缓存资源是 preloader 相干指令，也是页面优化的伎俩之一，能够做到解析脚本和CSS文件的同时申请下一个资源。 Disk CacheDisk Cache 存在于磁盘的缓存，读取尽管慢一点，然而能够实现长久化存储，并且容量比内存缓存要宽泛很多。 Disk Cache的覆盖面在浏览器中占用比重很大，通常联合HTTP头部字段进行判断，如果跨站点下载文件，曾经下载过的文件不会再次申请，而是间接从Disk Cache 获取。 如何判断缓存进内存还是进磁盘？通常有两个根据： 如果是大文件，通常会进入磁盘当中进行缓存。如果是频繁拜访的文件，也会放入磁盘。Push Cache推送缓存是HTTP/2 新退出的内容，下面三种状况都没有命中的时候才会尝试应用。它是会话级别缓存，一旦会话完结，也会立刻开释缓存，生命周期只比内存缓存长一点点。 缓存过程缓存的大抵流程如下： 客户端发动HTTP申请拜访浏览器缓存，浏览器不存在缓存，告知客户端让它从新发申请。客户端再次发动HTTP申请到原始服务器，原始服务器返回后果和缓存规定。客户端再次发动申请，从浏览器的缓存中获取申请后果。留神第一步是隐式解决的，所以缓存过程次要有两个要点： 每次申请都会查看浏览器是否存在缓存标识，以及申请的缓存后果。如果没有非凡字段禁用缓存，缓存将会把申请后果缓存存在浏览器缓存当中。缓存断定次要依赖两项技术：强制缓存和协商缓存，也是HTTP缓存技术的要点。将在下文进行进行介绍。 Pragma 头部Pragma 于 HTTP1.0 中定义，单词含意叫做“编译指令”，简直能够蕴含任何内容，目标是给浏览器发送申请中进行一些指令操作，然而次要的利用场景是缓存操控。 Pragma次要作用是放弃 HTTP1.0 向后兼容，因为缓存技术是在HTTP1.1中才呈现的。 比方让一些HTTP1.0的源服务辨认客户端了解”无缓存“的申请头部，这时候Prama就能够派上用场。 Pragma 如果被发送，将会利用于所有的应用程序和客户端。如果存在HTTP1.1缓存技术的相干申请头部字段，在服务器能够辨认的前提下，会优先解析HTTP1.1的申请头部，从而疏忽Pragma头部。 然而这里介绍的所有内容都是 HTTP1.0 约定俗成的货色。HTTP1.0 自身不能算作规范，只能算作“草稿”，所以 Pragma 既没有明确标准，也没有可靠性，当初的网络环境这个字段根本不再应用。仅仅是有可能的向后兼容场景中用到。 介绍这些内容，只是让大家晓得点历史。Pargma 头部应用形式 根本语法 Pragma: 1# pragma-directive举例 Pragma: no-cache（实际上也是惟一取值） 强制缓存强制缓存指的是只有浏览器没有过期，就应用缓存进行返回，主动性在浏览器方。 比方上面的申请当中，应用了缓存进行返回，强缓存利用两个响应头部实现， 绝对工夫“Cache-Control” 以及 "Expire"相对工夫 两个字段。 ...

　这篇文章会从上面几个维度来比照 HTTP 1.0 和 HTTP 1.1：　响应状态码　缓存解决　连贯形式　Host头解决　带宽优化　响应状态码　HTTP/1.0仅定义了16种状态码。HTTP/1.1中新退出了大量的状态码，光是谬误响应状态码就新增了24种。比如说，100 (Continue)——在申请大资源前的预热申请，206 (Partial Content)——范畴申请的标识码，409 (Conflict)——申请与以后资源的规定抵触，410 (Gone)——资源已被永恒转移，而且没有任何已知的转发地址。　缓存解决　缓存技术通过防止用户与源服务器的频繁交互，节约了大量的网络带宽，升高了用户接管信息的提早。　HTTP/1.0　HTTP/1.0提供的缓存机制非常简单。服务器端应用Expires标签来标记（工夫）一个响应体，在Expires标记工夫内的申请，都会取得该响应体缓存。服务器端在首次返回给客户端的响应体中，有一个Last-Modified标签，该标签标记了被申请资源在服务器端的最初一次批改。在申请头中，应用If-Modified-Since标签，该标签标记一个工夫，意为客户端向服务器进行问询：“该工夫之后，我要申请的资源是否有被批改过？”通常状况下，申请头中的If-Modified-Since的值即为上一次取得该资源时，响应体中的Last-Modified的值。　如果服务器接管到了申请头，并判断If-Modified-Since工夫后，资源的确没有批改过，则返回给客户端一个304 not modified响应头，示意”缓冲可用，你从浏览器里拿吧！”。　如果服务器判断If-Modified-Since工夫后，资源被批改过，则返回给客户端一个200 OK的响应体，并附带全新的资源内容，示意”你要的我曾经改过的，给你一份新的”。　HTTP/1.1　HTTP/1.1的缓存机制在HTTP/1.0的根底上，大大增加了灵活性和扩展性。根本工作原理和HTTP/1.0放弃不变，而是减少了更多粗疏的个性。其中，申请头中最常见的个性就是Cache-Control，详见MDN Web文档 Cache-Control.　连贯形式　HTTP/1.0 默认应用短连贯 ，也就是说，客户端和服务器每进行一次 HTTP 操作，就建设一次连贯，工作完结就中断连贯。当客户端浏览器拜访的某个 HTML 或其余类型的 Web 页中蕴含有其余的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会从新建设一个TCP连贯，这样就会导致有大量的“握手报文”和“挥手报文”占用了带宽。　为了解决 HTTP/1.0 存在的资源节约的问题， HTTP/1.1 优化为默认长连贯模式 。 采纳长连贯模式的申请报文会告诉服务端：“我向你申请连贯，并且连贯胜利建设后，请不要敞开”。因而，该TCP连贯将继续关上，为后续的客户端-服务端的数据交互服务。也就是说在应用长连贯的状况下，当一个网页关上实现后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连贯不会敞开，客户端再次拜访这个服务器时，会持续应用这一条曾经建设的连贯。　如果 TCP 连贯始终放弃的话也是对资源的节约，因而，一些服务器软件（如 Apache）还会反对超时工夫的工夫。在超时工夫之内没有新的申请达到，TCP 连贯才会被敞开。　有必要阐明的是，HTTP/1.0仍提供了长连贯选项，即在申请头中退出Connection: Keep-alive。同样的，在HTTP/1.1中，如果不心愿应用长连贯选项，也能够在申请头中退出Connection: close，这样会告诉服务器端：“我不须要长连贯，连贯胜利后即可敞开”。　HTTP 协定的长连贯和短连贯，本质上是 TCP 协定的长连贯和短连贯。　实现长连贯须要客户端和服务端都反对长连贯。　Host头解决　域名零碎（DNS）容许多个主机名绑定到同一个IP地址上，然而HTTP/1.0并没有思考这个问题，假如咱们有一个资源URL是http://example1.org/home.html，HTTP/1.0的申请报文中，将会申请的是GET /home.html HTTP/1.0.也就是不会退出主机名。这样的报文送到服务器端，服务器是了解不了客户端想申请的真正网址。　因而，HTTP/1.1在申请头中退出了Host字段。退出Host字段的报文头部将会是:　GET /home.html HTTP/1.1　Host: example1.org　这样，服务器端就能够确定客户端想要申请的真正的网址了。　带宽优化　范畴申请　HTTP/1.1引入了范畴申请（range request）机制，以防止带宽的节约。当客户端想申请一个文件的一部分，或者须要持续下载一个曾经下载了局部但被终止的文件，HTTP/1.1能够在申请中退出Range头部，以申请（并只能申请字节型数据）数据的一部分。服务器端能够疏忽Range头部，也能够返回若干Range响应。　如果一个响应蕴含局部数据的话，那么将带有206 (Partial Content)状态码。该状态码的意义在于防止了HTTP/1.0代理缓存谬误地把该响应认为是一个残缺的数据响应，从而把他当作为一个申请的响应缓存。　在范畴响应中，Content-Range头部标记批示出了该数据块的偏移量和数据块的长度。　状态码100　HTTP/1.1中新退出了状态码100。该状态码的应用场景为，存在某些较大的文件申请，服务器可能不违心响应这种申请，此时状态码100能够作为批示申请是否会被失常响应，过程如下图：　然而在HTTP/1.0中，并没有100 (Continue)状态码，要想触发这一机制，能够发送一个Expect头部，其中蕴含一个100-continue的值。　压缩　许多格局的数据在传输时都会做预压缩解决。数据的压缩能够大幅优化带宽的利用。然而，HTTP/1.0对数据压缩的选项提供的不多，不反对压缩细节的抉择，也无奈辨别端到端（end-to-end）压缩或者是逐跳（hop-by-hop）压缩。　HTTP/1.1则对内容编码（content-codings）和传输编码（transfer-codings）做了辨别。内容编码总是端到端的，传输编码总是逐跳的。　HTTP/1.0蕴含了Content-Encoding头部，对音讯进行端到端编码。HTTP/1.1退出了Transfer-Encoding头部，能够对音讯进行逐跳传输编码。HTTP/1.1还退出了Accept-Encoding头部，是客户端用来批示他能解决什么样的内容编码。　总结　连贯形式 : HTTP 1.0 为短连贯，HTTP 1.1 反对长连贯。　状态响应码 : HTTP/1.1中新退出了大量的状态码，光是谬误响应状态码就新增了24种。比如说，100 (Continue)——在申请大资源前的预热申请，206 (Partial Content)——范畴申请的标识码，409 (Conflict)——申请与以后资源的规定抵触，410 (Gone)——资源已被永恒转移，而且没有任何已知的转发地址。　缓存解决 : 在 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），这样就不便了开发者自在的抉择以便于充分利用带宽和连贯。　Host头解决 : HTTP/1.1在申请头中退出了Host字段。 ...

这篇文章会从上面几个维度来比照 HTTP 1.0 和 HTTP 1.1： 响应状态码缓存解决连贯形式Host头解决带宽优化响应状态码HTTP/1.0仅定义了16种状态码。HTTP/1.1中新退出了大量的状态码，光是谬误响应状态码就新增了24种。比如说，100 (Continue)——在申请大资源前的预热申请，206 (Partial Content)——范畴申请的标识码，409 (Conflict)——申请与以后资源的规定抵触，410 (Gone)——资源已被永恒转移，而且没有任何已知的转发地址。 缓存解决缓存技术通过防止用户与源服务器的频繁交互，节约了大量的网络带宽，升高了用户接管信息的提早。 HTTP/1.0HTTP/1.0提供的缓存机制非常简单。服务器端应用Expires标签来标记（工夫）一个响应体，在Expires标记工夫内的申请，都会取得该响应体缓存。服务器端在首次返回给客户端的响应体中，有一个Last-Modified标签，该标签标记了被申请资源在服务器端的最初一次批改。在申请头中，应用If-Modified-Since标签，该标签标记一个工夫，意为客户端向服务器进行问询：“该工夫之后，我要申请的资源是否有被批改过？”通常状况下，申请头中的If-Modified-Since的值即为上一次取得该资源时，响应体中的Last-Modified的值。 如果服务器接管到了申请头，并判断If-Modified-Since工夫后，资源的确没有批改过，则返回给客户端一个304 not modified响应头，示意”缓冲可用，你从浏览器里拿吧！”。 如果服务器判断If-Modified-Since工夫后，资源被批改过，则返回给客户端一个200 OK的响应体，并附带全新的资源内容，示意”你要的我曾经改过的，给你一份新的”。 HTTP/1.1HTTP/1.1的缓存机制在HTTP/1.0的根底上，大大增加了灵活性和扩展性。根本工作原理和HTTP/1.0放弃不变，而是减少了更多粗疏的个性。其中，申请头中最常见的个性就是Cache-Control，详见MDN Web文档 Cache-Control. 连贯形式HTTP/1.0 默认应用短连贯 ，也就是说，客户端和服务器每进行一次 HTTP 操作，就建设一次连贯，工作完结就中断连贯。当客户端浏览器拜访的某个 HTML 或其余类型的 Web 页中蕴含有其余的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会从新建设一个TCP连贯，这样就会导致有大量的“握手报文”和“挥手报文”占用了带宽。 为了解决 HTTP/1.0 存在的资源节约的问题， HTTP/1.1 优化为默认长连贯模式 。 采纳长连贯模式的申请报文会告诉服务端：“我向你申请连贯，并且连贯胜利建设后，请不要敞开”。因而，该TCP连贯将继续关上，为后续的客户端-服务端的数据交互服务。也就是说在应用长连贯的状况下，当一个网页关上实现后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连贯不会敞开，客户端再次拜访这个服务器时，会持续应用这一条曾经建设的连贯。 如果 TCP 连贯始终放弃的话也是对资源的节约，因而，一些服务器软件（如 Apache）还会反对超时工夫的工夫。在超时工夫之内没有新的申请达到，TCP 连贯才会被敞开。 有必要阐明的是，HTTP/1.0仍提供了长连贯选项，即在申请头中退出Connection: Keep-alive。同样的，在HTTP/1.1中，如果不心愿应用长连贯选项，也能够在申请头中退出Connection: close，这样会告诉服务器端：“我不须要长连贯，连贯胜利后即可敞开”。 HTTP 协定的长连贯和短连贯，本质上是 TCP 协定的长连贯和短连贯。 实现长连贯须要客户端和服务端都反对长连贯。 Host头解决域名零碎（DNS）容许多个主机名绑定到同一个IP地址上，然而HTTP/1.0并没有思考这个问题，假如咱们有一个资源URL是http://example1.org/home.html，HTTP/1.0的申请报文中，将会申请的是GET /home.html HTTP/1.0.也就是不会退出主机名。这样的报文送到服务器端，服务器是了解不了客户端想申请的真正网址。 因而，HTTP/1.1在申请头中退出了Host字段。退出Host字段的报文头部将会是: GET /home.html HTTP/1.1Host: example1.org这样，服务器端就能够确定客户端想要申请的真正的网址了。 ...

终、《图解HTTP》读书笔记 - 汇总篇（总结）引言又一本网络根底的书啃完了，这本书倡议联合[[《网络是怎么样连贯的》读书笔记 - 汇总篇]](https://segmentfault.com/a/11...)这一篇读书笔记食用（当然也能够间接看原书）。 把这两本书啃完对于整个互联网的根底脉络有一个大略的认知 在浏览这份汇总笔记之前，咱们先从全局看一下大略讲了什么内容。 幕布地址：读书笔记纲要 介绍HTTP的好书《HTTP 权威指南》，以及网络编程必看书《TCP/IP 详解，卷 1》都比拟难啃。我置信如果一上来就看这两本书，根本没有多少人能保持，更多的可能是看了几页之后立马丢到一边成为显示器脚垫。 这时候应该抉择降级抉择更低一档的入门书，也就是这篇读书笔记对应的书籍《图解HTTP》。 这本书的长处是简略理解HTTP的神秘面纱同时，能让你保持看下不会感觉干燥，尽管想要成为强人必须要通过下面两本书的磨难，然而在等级不够的时候，更倡议好好静心心来看这本书。 看完这本之后，能够再看看《图解TCP/IP》，算是啃黑皮书之前的最初一道内功，这本书对于OSI模型七层架构以及TCP/IP模型进一步论述。 再次强调，没有网络根底，不要上来先看《TCP/IP 详解》，否则你会感觉在看天书（过来人的教训）。 资源链接《图解HTTP》电子书资源链接： 链接: https://pan.baidu.com/s/1Zacp... 提取码: 7om2 如果生效能够到公众号“懒时小窝” 回复“图解HTTP”获取图书资源。 章节梳理入门章节（概览整个HTTP，理解HTTP定位）第一章（把握）：WEB 根底和HTTP的诞生，TCP/IP协定、URL和URI的理解，如果曾经很相熟了能够跳过。 \#知识点 概览HTTP诞生历史。文中提供一个中文翻译网站能够对照浏览。扩大：HTTP3.0 都曾经进去了，为什么2.0 推动还是只有一半？题外话探讨TCP/IP 协定概览，理解根本定义。辨别URL和URI。重点章节（必看并且消化以及自我复述）第二章（把握）：HTTP重点个性介绍。理解HTTP协定重点降级内容，了解加记忆为主。读书笔记补充了HTTPS的历史（必看） \#知识点 申请和响应报文的构造。HTTP协定进化历史，介绍不同HTTP版本从无到有的重大个性扭转。（重点）HTTP几个比拟常见的问题探讨。第三章（把握）：HTTP报文信息。报文是WEB的外围，须要重点把握。 \#知识点 HTTP 申请报文构造。申请报文和主体差别，介绍无关报文和主体相干的一些概念信息。内容协商：什么是内容协商？对于内容协商的几种形式。第七章（把握）：重点是SSL/TLS协定的把握，细节比拟多。 \#知识点 HTTPS 是什么？HTTP有哪些毛病？SSL、TLS为啥总是被放到一起，有什么区别？SSL、TLS历史背景。SSL的加密细节，加密算法理解。SSL的加密流程。第六章（相熟）：介绍HTTP头部内容。不须要记忆背诵，只须要用到的时候查表即可，此外记住一些常见头部应酬面试。 \#知识点 HTTP 申请报文构造。申请报文和主体差别，介绍无关报文和主体相干的一些概念信息。内容协商：什么是内容协商？对于内容协商的几种形式。非重点章节（知识点含糊则倡议仔细阅读）第四章（相熟）：常见HTTP状态码介绍，尽管同样也不须要记忆，只须要用到的时候查表，然而作为开发人员，常见的一些响应码须要把握并且留神细节。 \#知识点 状态码定义的IETF协定标准，应用 RFC 7231 作为协定参考。常见状态码定义，以及在 RFC 7231 中的协定定义参考如何抉择适合的状态码，这里仅介绍了 GET/POST/HEAD 三个最罕用的状态码定义参考。第八章（拓展）：身份认证形式的扩大浏览。重点相熟把握SSL认证，细节很多。（和第七章有重合，书籍编排问题） \#知识点 身份认证的几种常见形式 BASIC认证（根本认证）DIGEST认证（摘要认证）SSL客户端认证FormBase认证（表单认证）重点介绍SSL认证细节，其余认证形式能够不看或者跳过。Keberos 认证和NTLM 认证，Keberos 认证是大数据身份认证的事实标准，大数据相干畛域工作者有必要关注。选看章节（非重点，大部分能够跳，小局部需理解）第十一章（理解）：RSS介绍，WEB攻打与防护。WEB攻打局部有时候面试会问到，倡议理解一下。 \#知识点 RSS历史介绍，RSS的存在意义和价值，集体认为很适宜自主学习的人应用。WEB 攻打伎俩介绍，理解根底和常见的攻打伎俩，这些攻打伎俩离咱们日常生活并不远。对于瓶颈和将来倒退是因为写书时效性产生的一些“过期”内容，能够跳过。第十章（跳过）：构建WEB内容：和WEB无关搭配组件概念。也是泛泛而谈。 第九章（跳过）：HTTP的瓶颈和将来倒退。在写这本书的时候HTTP2.0还没进去，当初HTTP3.0都曾经倒退了不少了=-=，倡议看看读书笔记局部的第二个大章介绍。 第五章（跳过）：介绍代理、网关、隧道的大抵概念。其实就是介紹了局部互联网架构组件，讲的过于浅并且编排不是很好，倡议看《网络是怎么样连贯的》，另外自荐一下本人的读书笔记。 附录尽管题目起名叫“附录”，实际上是集体收集笔记而已。 附录局部是把之前各个章节参考的各种文章和材料汇总一遍，如果你也想浏览这本书，置信这些内容对你肯定有帮忙。 历史文章汇总如果不喜爱又臭又长的文章，倡议拆分浏览，体验更佳，本文为汇总实际上就是把这些文章合并到一起浏览。 当然不肯定非按我的编排形式，倡议依据本人的习惯来看即可。入门章节[[《图解HTTP》 - WEB和网络根底]](https://segmentfault.com/a/11...) ...

tjhttp N、《图解HTTP》读书笔记 - 附录介绍尽管题目起名叫“附录”，实际上是集体收集笔记而已。 附录局部是把之前各个章节参考的各种文章和材料汇总一遍，如果你也想浏览这本书，置信这些内容对你肯定有帮忙。 N1、HTTP历史协定白皮书如果要深刻开掘HTTP，那么必然绕不开这些协定原文写了啥，尽管在文章曾经给出超连贯，然而为了不便查找，这里还是留了一份。 HTTP0.9：这个就齐全是草稿了。HTTP/1.0：RFC1945 https://datatracker.ietf.org/doc/html/rfc1945HTTP1.1 https://tools.ietf.org/html/rfc7230https://tools.ietf.org/html/rfc7231https://tools.ietf.org/html/rfc7232https://tools.ietf.org/html/rfc7233https://tools.ietf.org/html/rfc7234https://tools.ietf.org/html/rfc7235HTTP2.0 https://datatracker.ietf.org/doc/rfc7540/HTTP3.0（订正中） https://datatracker.ietf.org/doc/rfc9114/这些内容的理解来源于这一篇博客：【RFC】HTTP/1.1 系列（7230 - 7235）。 留神 HTTP1.1 有些材料还在探讨 RFC2616，实际上早就曾经被废除了。 N2、HTML1.0Hypertext Markup Language (HTML) A Representation of Textual Information and MetaInformation for Retrieval and Interchange http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt N3、NCSA Mosaic bounce page1993 年秋天，Mosaic 的 Windows 版和 Macintosh 版面世。应用 CGI 技 术的 NCSA Web 服务器、NCSA HTTPd 1.0 也差不多是在这个期间出 现的。http://archive.ncsa.illinois.edu/mosaic.html The NCSA HTTPd Home Page（存档）http://web.archive.org/web/20090426182129/http://hoohoo.ncsa.illinois.edu/ （旧址已生效） N4、httpbis（Hypertext Transfer Protocol Bis）负责互联网技术标准的 IETF（Internet Engineering Task Force，互联网 工程工作组）创建 httpbis（Hypertext Transfer Protocol Bis，http://datatracker.ietf.org/w...）工作组，其指标是推动下一 代 HTTP——HTTP/2.0 在 2014 年 11 月实现标准化。 ...

4.1 状态码告知从服务器端返回的申请后果类别 起因短语 1XX Informational(信息性状态码) 接管的申请正在解决2XX Success(胜利状态码) 申请失常处理完毕3XX Redirection(重定向状态码) 须要进行附加操作以实现申请4XX Client Error(客户端谬误状态码) 服务器无奈解决申请5XX Server Error(服务器谬误状态码) 服务器解决申请出错仅记录在 RFC2616 上的 HTTP 状态码就达 40 种，若再加上 WebDAV(Web-based Distributed Authoring and Versioning，基于万维网 的分布式创作和版本控制)(RFC4918、5842) 和附加 HTTP 状态码 (RFC6585)等扩大，数量就达 60 余种。 4.2 2XX 胜利4.2.1 200 OK示意从客户端发来的申请在服务器端被失常解决了。 在响应报文内，随状态码一起返回的信息会因办法的不同而产生改 变。比方，应用 GET 办法时，对应申请资源的实体会作为响应返 回;而应用 HEAD 办法时，对应申请资源的实体首部不随报文主体 作为响应返回(即在响应中只返回首部，不会返回实体的主体部 分)。4.2.2 204 No Content该状态码代表服务器接管的申请已胜利解决，但在返回的响应报文中 不含实体的主体局部。另外，也不容许返回任何实体的主体。 4.2.3 206 Partial Content该状态码示意客户端进行了范畴申请，而服务器胜利执行了这部分的 GET 申请。响应报文中蕴含由 Content-Range 指定范畴的实体内容。 4.3 3XX 重定向3XX 响应结果表明浏览器须要执行某些非凡的解决以正确处理申请。 4.3.1 301 Moved Permanently永久性重定向。该状态码示意申请的资源已被调配了新的 URI，当前 应应用资源当初所指的 URI。也就是说，如果曾经把资源对应的 URI 保留为书签了，这时应该按 Location 首部字段提醒的 URI 从新保留。 ...

背景HTTP 中 Referer 字段在工作中或者并不会吸引你的留神，暗藏在 Network 的申请之下，然而却有着十分重要的作用。平时你肯定会遇到一些问题须要去排查，如果这个问题在你排查齐全部代码后，仍然没有解决，这个时候你会怎么办？此时咱们就须要将排查问题的角度转换一下，切换到 HTTP 协定上。最近工作当中也碰到了与此相关的一些问题，借此机会也同时做个记录和总结。HTTP 协定整体蕴含内容十分多，本次咱们只把其中的 Referer 字段拿进去和大家具体说一下。HTTP RefererReferer 是什么？HTTP Referer 是 HTTP 表头的一个字段，用来示意以后网页是来源于哪里，采纳的格局是 URL。咱们通过这个 HTTP Referer，能够查到访客的起源。能够通过 Network 面板看到，页面拜访及资源申请的 Request Headers 申请头信息里有一个 Referer 字段，用来标记起源的 URL。 有同学可能会留神到 Referer “仿佛”拼写有误，应该是 “Referrer" 才对，这其实是个历史起因，在晚期 HTTP 标准当中就存在的拼写错误，前面为了向下兼容，所以一误再误。拼写错误只有 Request Headers 的 “Referer”，在其余中央比方General Headers、 JavaScript 及 DOM 上，都是正确的拼写。General Headers： // javascriptdocument.referrer // DOM查看链接复制代码到此大家应该对 Referer 有了一个大略的理解，那么 Referer 字段在什么条件下会展现，以及如何去管制 Referer 返回的具体内容呢？答案就在 Referrer-Policy 当中，上面就带大家具体讲一下 Referrer-Policy 策略。Referrer-Policy 策略有哪些策略？Referrer-Policy: no-referrer顾名思义，这个策略示意不发送 Referer 信息。工作中理论应用的场景：在双品牌“乐彩云”推广中为升高双域名跳转革新老本，运维层面在Nginx增加了一个规定，若拜访链接（例如 news.zcygov.cn）的 Referer 蕴含 lecaiyun.com 域名，则会强制将拜访链接的域名变更为 lecaiyun.com ，实现链接跳转对立。若局部域名不须要走这一套逻辑，不携带 Referer 头信息，则须要指定 Referrer-Policy 策略为 no-referrer 。 ...

ETAG 属于条件申请(Conditional Request)领域下的概念。 条件申请是浏览器能够询问服务器是否有更新的资源正本的申请。 浏览器将发送一些对于它所持有的缓存资源的信息，服务器将确定是否应该返回更新的内容或者浏览器的正本是最新的。 在后者的状况下，返回 304（未修改）的 HTTP 状态。通过设置 ETag 或 Last-Modified，能够触发 HTTP 申请头部字段中提到的 If-Modified-Since 或 If-None-Match 申请字段。 当正确配置的 Web 服务器看到来自客户端的这些传入的申请标头时，服务器能够确认浏览器在其 HTTP 缓存中曾经领有的资源版本是否与 Web 服务器上的最新版本匹配。 如果匹配，则服务器能够响应 304 Not Modified HTTP 响应，相当于通知客户端即浏览器，请持续应用你曾经领有的资源。 服务器发送这种类型的响应时，须要传输的数据非常少，因而通常比必须理论发送回所申请的理论资源的正本要快得多。这是因为，只管条件申请的确会通过网络调用调用，但未修改的资源会导致响应主体为空——节俭了将资源传输回最终客户端的老本。 后端服务通常还可能十分疾速地确定资源的最初批改日期，而无需拜访资源，这自身能够节俭大量的解决工夫。 上图的例子是，浏览器从服务器申请 /file 并蕴含 If-None-Match 标头，以批示服务器仅在服务器上文件的 ETag 与浏览器的 If-None-Match 值不匹配时，才返回残缺文件。 在这种状况下，这 2 个值的确匹配，因而服务器返回 304 Not Modified 响应，其中蕴含无关文件应缓存多长时间的阐明（缓存管制：max-age=120）。

tjhttp 七、《图解HTTP》- HTTP首部和HTTP合作服务器 7-1. HTTP首部尽管平时感触不到，然而却是互联网天天在用的货色，这本书花了50多页的内容介绍它，可见它的重要性。 HTTP 首部蕴含三个局部，报文首部，空行和报文主体，报文首部蕴含了客户端重要的传输信息，而报文体则是“负荷数据”，蕴含获取服务器信息须要传递的数据。 HTTP 报文由办法、URI、HTTP 版本、HTTP 首部字段等局部形成。 上面是申请报文的案例信息： GET / HTTP/1.1Host: hackr.jpUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*; q=0.8Accept-Language: ja,en-us;q=0.7,en;q=0.3Accept-Encoding: gzip, deflateDNT: 1Connection: keep-aliveIf-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMTIf-None-Match: "45bae1-16a-46d776ac"Cache-Control: max-age=0响应报文构造如下： 响应报文内容： HTTP/1.1 304 Not ModifiedDate: Thu, 07 Jun 2012 07:21:36 GMTServer: ApacheConnection: closeEtag: "45bae1-16a-46d776ac"7.0 首部字段介绍首部字段是HTTP的重要组成部分。 HTTP 首部字段构造 首部字段由key/value的字段名和字段值组成，通过冒号进行分隔，字段值能够是单个值，也能够是多个值，对于多个值会应用逗号进行分隔。 如果首部字段呈现重叠怎么办？在标准当中并没有进行明确规定，取决于浏览器和实现方是如何解决的，比方有些浏览器会优先解决第一次呈现的首部字段，而有些则会优先解决最初呈现的首部字段。 首部字段分类 通用首部字段（General Header Fields）：申请和响应通用首部。申请首部字段（Request Header Fields）：从客户端向服务器端发送申请报文时应用的首部。响应首部字段（Response Header Fields）：从服务器端向客户端返回响应报文时应用的首部。负载（实体）首部字段（Entity Header Fields）：在负载的局部应用的首部信息，客户端和服务端都有可能存在。HTTP/1.1 首部字段 ...

tjhttp 五、《图解HTTP》- RSS和网络攻击本节是对于RSS和常见网络攻击的探讨，RSS仿佛总是被认为“为什么还没有隐没“的货色，然而集体通过理解和体验之后发现意外的挺好用的，这里补充了一下RSS历史，如果感兴趣能够拜访集体在参考资料提供了一些应用RSS的软件和更具体介绍链接。 而对于网络攻击的局部有时候会成为面试的考点，理解根底的网络攻击伎俩和常见的防备形式还是有必要的。 5.1 RSS5.1.1 RSS历史上面大部分内容来自维基百科，因为多半是实践内容，不做过多解释。 RSS（简略信息聚合）和Atom都是针对新闻和博客日志信息文档格局的合称。 RSS（英文全称：RDF Site Summary 或 Really Simple Syndication）中文译作繁难信息聚合，也称聚合内容，是一种消息来源格局标准，用以聚合多个网站更新的内容并主动告诉网站订阅者。 应用 RSS 后，网站订阅者便无需再手动查看网站是否有新的内容，同时 RSS 可将多个网站更新的内容进行整合，以摘要的模式出现，有助于订阅者疾速获取重要信息，并选择性地点阅查看。 RSS的历史版本更新如下： RSS 0.9（RDF Site Summary）：最后的 RSS 版本。1999 年 3 月由网 景通信公司自行开发用于其门户网站。根底构图创立在初期的 RDF 规格上。RSS 0.91（Rich Site Summary）：在 RSS0.9 的根底上扩大元素，于 1999 年 7 月开发结束。非 RDF 规格，应用 XML 形式编写。RSS 1.0（RDF Site Summary）：RSS 规格正处于混乱状态。2000 年 12 月由 RSS-DEV 工作组再次采纳 RSS0.9 中应用的 RDF 规格公布。RSS2.0（Really Simple Syndication）：非 RSS1.0 倒退路线。减少支 持 RSS0.91 的兼容性，2000 年 12 月由 UserLand Software 公司开发完 成。倒退到当初RSS有几个不同的版本，分为两个次要分支（RDF和2.X）。 ...

tjhttp 六、《图解HTTP》- 用户身份认证6.1 概览常见的用户身份认证形式： 明码动静令牌数字证书生物物证IC卡在HTTP1.1中通常存在上面几种认证形式： BASIC认证（根本认证）：DIGEST认证（摘要认证）：SSL客户端认证FormBase认证（表单认证）6.2 SSL认证因为SSL认证是咱们日常开发根底最多的的，所以首先来了解一下。 SSL是同时应用对称加密和非对称加密的形式，在链接的过程中应用非对称加密，而在连贯之后应用对称加密，相似在两边先通过身份牌意识单方，而后用特定的通行证实现单方的通信。 安全套接字层 (SSL) 技术通过加密信息和提供鉴权，爱护您的网站平安。一份 SSL 证书包含一个公共密钥和一个私用密钥。公共密钥用于加密信息，私用密钥用于解译加密的信息。浏览器指向一个平安域时，SSL 同步确认服务器和客户端，并创立一种加密形式和一个惟一的会话密钥。它们能够启动一个保障音讯的隐衷性和完整性的平安会话。 6.2.1 根本工作原理对于SSL的认证形式，根本的流程如下（留神这里省略一步是客户端须要装置SSL证书）： 客户端发送申请，服务端接管到认证资源，同时发送Certificate Request报文，同时要求客户端提供证书。用户抉择客户端证书通过Client Certificate报文的形式传给服务器。服务器验证客户端证书拿到客户端的密钥信息，之后开始HTTPS对称加密通信。当然书中提到的含糊的交互过程，上面是对于SSL两种认证形式的区别和细节： 6.2.2 单向认证单向认证在整个SSL握手流程中仅仅单向验证了服务器的SSL证书。因而这个单向认证过程使客户端浏览器能够连贯到正确的网站服务器，并且仅通过平安连贯将所有数据传输到指标站点。 客户端发送SSL协定版本号，加密算法，随机数等信息。服务端给客户端回传客户端所发送的这一类信息，同时返回服务端的证书，也就是公钥证书。客户端校验服务端证书的合法性，非法正确通信，否则进行通信并且正告，具体内容如下： 证书是否过期。发行服务器CA可靠性。返回公钥是否正确解开并且和服务器的理论域名匹配。服务器证书域名是否和服务器的理论域名匹配。客户端发送本人反对的加密计划，提供服务器抉择。服务器抉择提供的加密计划中加密水平最高的计划。服务器选好加密计划通过明文形式发给客户端。客户端收到加密计划应用计划生成随机码，以此作为对称加密的密钥，服务端返回的公钥加密，加密后的随机码发给服务器。服务端收到客户端的加密信息之后，用本人私钥解密并且对称加密密钥。服务端和客户端应用随机生成的明码进行对称加密，保障信息安全。 6.2.3 双向认证次要的步骤和单向认证统一，这里仅仅介绍有差异的步骤，次要差异是在客户端发送加密形式之前，服务端会多一步索要客户端证书的步骤，而后在抉择好加密形式之后不是通过明文的形式而是通过客户端给的公钥进行加密再进行返回。而其余步骤根本依旧，最终改变如下： 客户端发送本人反对的加密计划，提供服务器抉择。在此之前插入两个步骤 =>服务端要求客户端发送客户端的证书，客户端会将本人的证书发送至服务端。验证客户端证书，通过认证取得客户端公钥。服务器选好加密计划通过明文形式发给客户端之后增加 => 加密形式通过之前获取的公钥进行加密（不应用明文），返回给客户端。6.3 表单认证表单认证也就是咱们常说的账号密码登录。绝大多数的网站根本应用表单认证+SSL认证联合的形式，根本能保障99%的申请能建设平安链接，保障客户的信息不被窃取。然而因为表单认证没有标准和规范，品质也参差不齐，所以不是所有网站有表单认证就是平安的，然而有比没用强不少。 6.4 Cookie和Session治理Cookie 和 Session 作为HTTP无状态的一种用户信息暂存的补救机制，作用是让客户在登录某个网站之后能够放弃一段时间或者很长一段时间不须要从新登录，或者说保留一些网站的账户明码登录的时候主动填充，总之是晋升浏览器应用体验的货色。 Cookie 和 Session 通常是一起作用的，上面是客户登录中 Cookie 和 Session 作用的根本流程： 客户端通过表单发送信息服务器进行表单认证。服务器认证发送SessionID，把用户认证状态和SessionID绑定。向客户端返回响应时，会在首部字段 Set-Cookie 内写入 Session ID（如 PHPSESSID=028a8c…）。客户端承受SessionId作为Cookie保留本地，下次再次申请会带入Cookie并且随着SessionId一起发送，服务端基于SessionId辨认用户和认证状态。SessionID应该保障其安全性和难以揣测的个性，常见解决形式应用加盐对于明码进行二次的哈希解决，这种形式是应用比拟多的形式，避免XSS攻打获取到密文之后解密取得账户明码。 为加重跨站脚本攻打（XSS）造成的损失，倡议当时在 Cookie 内加上 httponly 属性。6.5 BASIC 认证和DIGEST 认证6.5.1 BASIC 认证BASIC 认证（根本认证）是从 HTTP/1.0 就定义的认证形式。还有极少局部网站在应用，作为大略理解即可。 大抵步骤如下： 须要 BASIC 认证时，服务器会随状态码 401 Authorization Required，返回带WWW-Authenticate首部字段的响应。状态码 401 Authorization Required告诉客户端须要BASIC认证。为了通过BASIC认证，须要把ID明码发给客户端，加密办法是串联用户ID和明码用连接符冒号链接，而后Base64加密。服务器接管到蕴含首部字段 Authorization 申请，而后返回一条Request-URI响应。 ...

tjhttp 四、《图解HTTP》- 状态码状态码这一张内容过于贫乏，参考资料找了一个澳大利亚的博客，外面收录了HTTP的状态码介绍，为什么选这个作参考？一个是网站挺丑陋，另一个是做了一张长图包容了常见的响应码，存到手机能够时不时看看，并且博客有做国际化，点进去主动就是中文（然而团队的确是外国人），挺有意思的。 另外须要留神汇总图是英文的，为了不失落HTTP状态码的本意，倡议先翻一翻RFC协定原文是如何定义的，通过网络查找国内几个点击率很高的比方菜鸟教程比照了解，集体并不倡议齐全看中文理解状态码含意，英文原文更加贴合定义转义同时外面还有一些小细节。 《图解HTTP》所介绍的HTTP1.1版本均为 RFC 2616的形容，很多内容其实曾经过期或者间接废除了！切记！ 互联网的一手信息根本都是英文的，编程学习的深刻总有一天要直面纯英文。注意事项查看具体内容之前，咱们须要理解最早的正式HTTP1.1协定版本公认为 RFC 2616，然而后续呈现了更多的修订版，补充了更多无关响应码和欠缺细节，比方当初的HTTP1.1 早就是 RFC 723X 结尾了。 另外为了不便读者理解协定原文，每一个大题目做了超链接，能够间接点击题目拜访以后最新的协定网站。（局部博客平台markdown解析可能没法点击，在每一个题目结尾也给了链接） 从协定公布节点来看，2014年的RFC723X结尾的协定能够认为是HTTP1.1的最初的更新版本。 本文介绍的状态码在 RFC2616 很多都是没定义的，RFC2616 很老了早就曾经废除了！ 具体的内容见： RFC2068：https://tools.ietf.org/html/rfc2068：过期的RFC2616： https://tools.ietf.org/html/rfc2616：过期的RFC7230： https://tools.ietf.org/html/rfc7230RFC7231：https://tools.ietf.org/html/rfc7231RFC7232： https://tools.ietf.org/html/rfc7232RFC7233： https://tools.ietf.org/html/rfc7233RFC7234： https://tools.ietf.org/html/rfc7234RFC7235： https://tools.ietf.org/html/rfc7235RFC7230：语法和路由 语法：形容了一个 HTTP 申请或者响应长什么样。即第一行写什么怎么写、第二行写什么怎么写... 路由：资源标识（URI）如何确定？通过什么形式获取到想要的内容？是间接从本地缓存获取？还是通过代理（Proxy）获取？还是间接申请？RFC7231：语义和内容（最须要关注的内容，RESTful-like） 各种申请办法（GET、POST、DELETE 等等）和申请头（Expect、Accept-Language、User-Agent 等等）表白了什么用意？ 响应体的状态（200 OK、201 Created、403 Forbidden 等等）和响应头（Location、Retry-After、Allow 等等）表白什么意思？RFC7232：条件申请 响应体告知客户端某些数据条件（Last-Modified、ETag 等等），客户端能够在下次申请的时候带上这些信息（If-Modified-Since、If-Match 等等）。在符合条件或者不符合条件的状况下，服务端应该如何解决；RFC7233：范畴申请 因为各种因素而只失去局部响应的时候，发动范畴申请以获取剩下的内容，防止从头申请而浪费资源；RFC7234：缓存 通过缩小申请防止网络资源的节约；RFC7235：认证 用户认证。Basic Auth、Token 等等。4.1 状态码定义1XX：1XX结尾多为信息提示信息，简直看不到应用场景，疏忽即可。此外1XX的状态码并不会影响到SEO 优化。2XX： HTTP状态代码是胜利申请。 比方HTTP 200 OK胜利状态响应代码批示申请已胜利。3XX：HTTP状态代码批示重定向。 最常见的 3XX HTTP状态代码包含“ 301永恒挪动”，“找到302”和“ 307长期重定向” HTTP状态代码。4XX 状态代码是客户端谬误。 最常见的4xx状态代码是“ 404未找到”和“ 410隐没” HTTP状态代码。5XX HTTP状态代码是服务器谬误。 最常见的5xx HTTP状态代码是“ 503服务不可用”状态代码。常见状态码定义1XX申请简直用不到，不须要理解，这里跳过。 4.1.1 2XX：申请胜利HTTP1.1 协定原文： ...

防盗链：只容许某些域名申请起源才能够拜访首先在正规的机器上设置虚拟主机装置httpd批改配置文件 设置虚拟主机 编辑虚拟主机的配置文件 编辑网站的配置 上传图片 启动服务测试是否胜利 启动胜利启动盗版网站的机器装置httpd 批改配置文件设置盗版网页配置文件 设置主机host文件 启动盗版的服务 盗版网站盗图胜利了上面设置防盗链查看源主机是否装置了防盗链的模块 在配置文件中增加防盗链模块 上面在配置中的设置防盗链属性 设置/opt/ab 重启源主机服务systemctl stop httpdsystemctl start httpd 盗版网站胜利拜访到正规的防盗链网站上

二、《图解HTTP》- HTTP协定历史倒退（重点）2.0 介绍这一章节基本上大部分为集体扩大，因为书中的内容讲的切实是比拟浅。本文内容十分长，另外哪怕这么长也只是讲到了HTTP协定的一部分而已，HTTP协定自身十分复杂。 2.1 申请和响应报文构造申请报文的根本内容： 申请内容须要客户端发给服务端： GET /index.htm HTTP/1.1 Host: hackr.jp响应报文的根本内容： 服务器依照申请内容处理结果返回： 结尾局部是HTTP协定版本，紧接着是状态码 200 以及起因短语。下一行则蕴含了创立响应的日期工夫，包含了首部字段的属性。 HTTP/1.1 200 OK Date: Tue, 10 Jul 2012 06:50:15 GMT Content-Length: 362 Content-Type: text/html<html> ……2.2 HTTP进化历史协定版本解决的外围问题解决形式0.9HTML 文件传输确立了客户端申请、服务端响应的通信流程1.0不同类型文件传输设立头部字段1.1创立/断开 TCP 连贯开销大建设长连贯进行复用2并发数无限二进制分帧3TCP 丢包阻塞采纳 UDP 协定SPDYHTTP1.X的申请提早多路复用2.2.1 概览咱们复盘HTTP的进化历史，上面是抛去所有细节，整个HTTP连贯大抵的进化路线。 留神：无关协定的降级内容挑了具备代表性的局部，残缺内容须要浏览RFC原始协定理解http0.9：只具备最根底的HTTP连贯模型，在十分短的一段时间内存在，前面被疾速欠缺。http1.0： 1.0版本中每个TCP连贯只能发送一个申请，数据发送结束连贯就敞开，如果还要申请其余资源，就必须从新建设TCP连贯。（TCP为了保障正确性和可靠性须要客户端和服务器三次握手和四次挥手，因而建设连贯老本很高）http1.1： 长连贯：新增Connection字段，默认为keep-alive，放弃连接不断开，即 TCP 连贯默认不敞开，能够被多个申请复用；管道化：在同一个TCP连贯中，客户端能够发送多个申请，但响应的程序还是依照申请的程序返回，在服务端只有解决完一个回应，才会进行下一个回应；host字段：Host字段用来指定服务器的域名，这样就能够将多种申请发往同一台服务器上的不同网站，进步了机器的复用，这个也是重要的优化；HTTP/2： 二进制格局：1.x是文本协定，然而2.0是以二进制帧为根本单位，能够说是一个二进制协定，将所有传输的信息宰割为音讯和帧，并采纳二进制格局的编码，一帧中蕴含数据和标识符，使得网络传输变得高效而灵便；多路复用：2.0版本的多路复用多个申请共用一个连贯，多个申请能够同时在一个TCP连贯上并发，次要借助于二进制帧中的标识进行辨别实现链路的复用；头部压缩：2.0版本应用应用HPACK算法对头部header数据进行压缩，从而缩小申请的大小提高效率，这个十分好了解，之前每次发送都要带雷同的header，显得很冗余，2.0版本对头部信息进行增量更新无效缩小了头部数据的传输；服务端推送：在2.0版本容许服务器被动向客户端发送资源，这样在客户端能够起到减速的作用；HTTP/3：这个版本是划时代的扭转，在HTTP/3中，将弃用TCP协定，改为应用基于UDP协定的QUIC协定实现。须要留神QUIC是谷歌提出的（和2.0 的SPDY 一样），QUIC指的是疾速 UDP Internet 连贯，既然应用了UDP，那么也意味着网络可能存在丢包和稳定性降落，谷歌当然不会让这样的事件产生，所以他们提出的QUIC既能够保障稳定性，又能够保障SSL的兼容，因为HTTP3上来就会和TLS1.3一起上线。 基于这些起因，制订网络协议IETF的人马上根本都批准了QUIC的提案（太好了又能白嫖成绩），于是HTTP3.0 就这样来了。然而这只是最根本的草案，后续的探讨中心愿QUIC能够兼容其余的传输协定，最终的排序如下IP / UDP / QUIC / HTTP。另外TLS有一个细节优化是在进行连贯的时候浏览器第一次就把本人的密钥替换的素材发给服务器，这样进一步缩短了替换的工夫。 为什么HTTP3.0要从协定基本上动刀，那是因为HTTP/2尽管解决了HTTP协定无奈多路复用的问题，然而没有从T CP层面解决问题，具体的TCP问题体现如下： 队头阻塞，HTTP/2 多个申请跑在一个 TCP 连贯中，如果此时序号较低的网络申请被阻塞，那么即便序列号较高的 TCP 段曾经被接管了，应用层也无奈从内核中读取到这部分数据，从 HTTP 视角看就是多个申请被阻塞了，并且页面也只是加载了一部分内容；TCP 和 TLS 握手时延缩短：TCL 三次握手和 TLS 四次握手，共有 3-RTT 的时延，HTPT/3最终压缩到1 RTT（难以想象有多快）；连贯迁徙须要从新连贯，挪动设施从 4G 网络环境切换到 WIFI 时，因为 TCP 是基于四元组来确认一条 TCP 连贯的，那么网络环境变动后，就会导致 IP 地址或端口变动，于是 TCP 只能断开连接，而后再从新建设连贯，切换网络环境的老本高；RTT：RTT是Round Trip Time的缩写，简略来说就是通信一来一回的工夫。上面是官网对于RTT速度缩短的比照，最终只在首次连贯须要1RTT的密钥替换，之后的连贯均为0RTT！ ...

零碎版本：centos7 批改配置文件 重启服务 再次应用浏览器拜访，而后应用抓包软件查看

零碎版本：centos7 开始源码编译批改配置文件在行尾增加 查看是否胜利 查看模块 应用抓包软件查看

零碎版本：centos7cd到源码编译文件 增加新的模块开始编译 关上Apache主配置文件 在行尾增加（shift+G） 换了个背景色彩 批改网页的图片 再应用抓包软件

一、《图解HTTP》- WEB和网络根底1.1 本章重点结尾局部是对于WEB和网络历史介绍，所以没有多少须要了解和记忆的内容。网络根底 TCP/IP的局部是整个互联网的外围，倡议多看几遍了解和消化。 WEB的传输依赖HTTP（HyperText Transfer Protocol，超文本传输协定 1 ）的协定作为标准，HTTP的工作是实现从客户端到服务器端等一系列运作流程，为了保障两台不同的设施能失常沟通，两者须要恪守雷同的规定。 目前HTTP曾经倒退到3.0了，然而这本书写下来的时候2.0还在起草，所以能够认为是一本比拟“老”的书，很多中央须要查阅以后的材料进行纠正。 1.2 HTTP诞生1989 年 3 月HTTP在少数几个人手中诞生。CERN（欧洲核子钻研组织）的蒂姆 • 伯纳斯 - 李（Tim BernersLee）提出网络通信的构想。 1990 年 11 月，CERN 胜利研发了世界上第一台 Web 服务器和 Web 浏 览器。 1990 年，大家针对 HTML 1.0 草案进行了探讨，因 HTML 1.0 中存在 多处模糊不清的局部，草案被间接废除了。 1993 年 1 月，古代浏览器的先人 NCSA（National Center for Supercomputer Applications，美国国家超级计算机利用核心）研发的 Mosaic 问世了。同年秋天公布Windows 版和 Macintosh 版面世。 1994 年 的 12 月，时代的眼泪网景通信公司公布了 Netscape Navigator 1.0，1995 年微软公司公布臭名远扬的 Internet Explorer 1.0 和 2.0，随后IE折磨开发人员数十年的历史开始。 这里有一个互联网比拟出名的历史，那就是对于微软和网景之间的浏览器抢夺，感兴趣的同学能够查查这一段历史，微软最终凭借Windows平台的客户粘性绑定以及收费博得胜利，网景尽管赢了官司然而浏览器市场被Windows垄断逐步败落，毕竟explore不免费谁奈何的了我。 当初的FireFox浏览器前身就是网景，不过浏览器内核却是谷歌一家独大，Edge在chrome内核以及本身优化的加持下也可圈可点，然而微软利用平台强制绑定客户的行为仍旧可见一二，这都是古代的用户能够感知的。 ...

本周刊记录乏味好玩的独立产品设计开发相干内容，每周公布，感兴趣的搭档能够点击订阅我的周刊。为保障每期都能收到，倡议邮件订阅。欢送通过 Twitter 私信举荐或投稿。产品举荐And notes - 这是一款新的笔记应用程序，目前处于测试阶段，仅实用于iOS。外围性能是智能文件夹，能够依据你的笔记标签把你的笔记组织成动静文件夹。另外还有个 Tag Network 的性能视图很有意思，能够预约一下，预计8月上线。 puter - 作者说这是一个在线记事本工具，你能够登录账号保留你的内容记录，另外这个网站有意思的是模仿了电脑桌面的格调，尽管桌面模仿的很不错，然而记事本的性能切实是太难用了。相似开源的模仿桌面我的项目太多了，Github 搜一大把，模仿 Windows 和 Mac 的都有。 Movemap - 这是一个小工具，能够应用它来依据本人的爱好来确定美国哪个中央更适宜你寓居。交互非常简单，这个网站有美国的待业，买房，租房老本，天气，税收累赘，教育等数据，依据你的筛选来看哪个城市最适宜你。做的十分好。 skal.es - 这个网站能够计算你的工作和生存是不是均衡的，work/life balance ⚖️分数越高阐明你的幸福指数越高，我测了一下43分。枯了。 flowful - 这是一个听 Ambient (环境) Music 的播放器网站我的项目， Ambient (环境) Music 是一种具备空间感的电子乐，常较关注声音材质，多反复，无歌词或谱曲。很适宜写代码工作的时候听。我试了一下感觉这类音乐也很适宜冥想♂️ 产品做的很残缺，设计上有些细节还不是很好，不过整体是一个很不错的独立开发的我的项目。如果能做多端的话是很不错的一个方向。开发者：@drewclicks。 stooge - 只是一个在线创立小漫画的网站，基于开源我的项目 comicgen 做的一个产品，还挺有意思的。能够用来疾速制作一个四格对话模式的小漫画。这个产品方向挺好玩的，很细分的一个漫画方向。 GP Calendar - 世界一级方程式锦标赛赛程日历的软件，能够间接展现在 Mac 的 menu bar。k开发者：@SlamingDev AirShot - Dynamic wallpaper 正在限免的一个 Mac 动静壁纸利用，限免到7月底。这个利用能够把你本人的地位的卫星地图设置为桌面壁纸，你也能够抉择随机一个中央的地图作为桌面壁纸。很有创意，是一个买断制的付费小工具。当初限免能够下载玩一玩，创意很不错。 Stario Launcher (发射) - 这是一个极简的桌面启动器，这类极简的桌面产品也十分多，大多数连图标都没有。为了让本人远离手机的一部分人有这个需要，当初的确应用手机的工夫越来越多，性能越来越简单。这类产品还是挺不错的。 AvaMaker - 这是一个收费的在线头像制作工具。能够下载 PNG 和 SVG。 SND.dev - 这是一个界面交互的声音素材汇合。大家都晓得 UI/UX设计，声音设计应该比拟生疏。除了游戏等一些畛域之外，如同没有对于声音交互设计的常识。交互不应该局限于文字和视觉，而应该更丰盛。互动应该更加丰盛和强烈， ...

1、告知服务器用意的 HTTP 办法(1) GET :获取资源GET 办法用来申请拜访已被 URI 辨认的资源。指定的资源经服务器 端解析后返回响应内容。也就是说，如果申请的资源是文本，那就保 持原样返回;如果是像 CGI(Common Gateway Interface，通用网关接 口)那样的程序，则返回通过执行后的输入后果。申请GET /index.html HTTP/1.1 Host: www.hackr.jp If-Modified-Since: Thu, 12 Jul 2012 07:30:00 GMT响应仅返回2012年7 月12日7 点30分当前更新过的index.html页面资源。如果未 有内容更新，则以状态码304 Not Modified作为响应返回(2) POST:传输实体主体POST 办法用来传输实体的主体。 申请POST /submit.cgi HTTP/1.1 Host: www.hackr.jp Content-Length: 1560(1560字节的数据)响应返回 submit.cgi 接收数据的处理结果(3) PUT:传输文件鉴于 HTTP/1.1 的 PUT 办法本身不带验证机制，任何人都能够 上传文件 , 存在安全性问题，因而个别的 Web 网站不应用该办法。若 配合 Web 应用程序的验证机制，或架构设计采纳(4) HEAD:取得报文首部HEAD 办法和 GET 办法一样，只是不返回报文主体局部。用于确认 URI 的有效性及资源更新的日期工夫等。(5) DELETE:删除文件DELETE 办法用来删除文件，是与 PUT 相同的办法。DELETE 办法按 申请 URI 删除指定的资源。然而，HTTP/1.1 的 DELETE 办法自身和 PUT 办法一样不带验证机 制，所以个别的 Web 网站也不应用 DELETE 办法。当配合 Web 利用 程序的验证机制，或恪守 REST 规范时还是有可能会凋谢应用的。 ...

从HTTP/1.0开始，始终到HTTP/2，不论应用层协定如何改良，TCP始终以来都是HTTP协定的根底，次要是因为他能提供牢靠连贯。 然而，从HTTP 3.0开始，这个状况就有所变动了。 因为，在最新推出的HTTP 3.0中，曾经彻底启用TCP协定了。 TCP队头阻塞咱们晓得，TCP传输过程中会把数据拆分为一个个依照程序排列的数据包，这些数据包通过网络传输到了接收端，接收端再依照程序将这些数据包组合成原始数据，这样就实现了数据传输。 然而如果其中的某一个数据包没有依照程序达到，接收端会始终放弃连贯期待数据包返回，这时候就会阻塞后续申请。这就产生了TCP队头阻塞。 HTTP/1.1的管道化长久连贯也是使得同一个TCP链接能够被多个HTTP应用，然而HTTP/1.1中规定一个域名能够有6个TCP连贯。而HTTP/2中，同一个域名只是用一个TCP连贯。 所以，在HTTP/2中，TCP队头阻塞造成的影响会更大，因为HTTP/2的多路复用技术使得多个申请其实是基于同一个TCP连贯的，那如果某一个申请造成了TCP队头阻塞，那么多个申请都会受到影响。 TCP握手时长咱们都晓得TCP的牢靠连贯是基于三次握手与四次挥手实现的。然而问题是三次握手是须要耗费工夫的。 TCP三次握手的过程客户端和服务器之间须要交互三次，那么也就是说须要额定耗费1.5 RTT。 RTT：网络提早（Round Trip Time）。他是指一个申请从客户端浏览器发送一个申请数据包到服务器，再从服务器失去响应数据包的这段时间。RTT 是反映网络性能的一个重要指标。在客户端和服务端间隔比拟远的状况下，如果一个RTT达到300-400ms，那么我握手过程就会显得很”慢”了。 降级TCP基于下面咱们提到的两个问题，有人提出来说：既然TCP存在这些问题，并且咱们也晓得这些问题的存在，甚至解决方案也不难想到，为什么不能对协定自身做一次降级，解决这些问题呢？ 其实，这就波及到一个”协定僵化“的问题。 这样讲，咱们在互联网上浏览数据的时候，数据的传输过程其实是极其简单的。 咱们晓得的，想要在家里应用网络有几个前提，首先咱们要通过运行商开明网络，并且须要应用路由器，而路由器就是网络传输过程中的一个中间设备。 中间设备是指插入在数据终端和信号转换设施之间，实现调制前或解调后某些附加性能的辅助设施。例如集线器、交换机和无线接入点、路由器、平安解调器、通信服务器等都是中间设备。 在咱们看不到的中央，这种中间设备还有很多很多，一个网络须要通过无数个中间设备的转发能力达到终端用户。 如果TCP协定须要降级，那么意味着须要这些中间设备都能反对新的个性，咱们晓得路由器咱们能够从新换一个，然而其余的那些中间设备呢？尤其是那些比拟大型的设施呢？更换起来的老本是微小的。 而且，除了中间设备之外，操作系统也是一个重要的因素，因为TCP协定须要通过操作系统内核来实现，而操作系统的更新也是十分滞后的。 所以，这种问题就被称之为”中间设备僵化”，也是导致”协定僵化”的重要起因。这也是限度着TCP协定更新的一个重要起因。 所以，近些年来，由IETF标准化的许多TCP新个性都因不足广泛支持而没有失去宽泛的部署或应用！ QUIC所以，摆在HTTP/3.0背后的就只有一条路，那就是放弃TCP。 于是，HTTP/3.0在基于UDP+迪菲赫尔曼算法（Diffie–Hellman）之上实现了QUIC协定（Quick UDP Internet Connections）。 QUIC协定有以下特点： 基于UDP的传输层协定：它应用UDP端口号来辨认指定机器上的特定服务器。 可靠性：尽管UDP是不牢靠传输协定，然而QUIC在UDP的根底上做了些革新，使得他提供了和TCP相似的可靠性。它提供了数据包重传、拥塞管制、调整传输节奏以及其余一些TCP中存在的个性。 实现了无序、并发字节流：QUIC的单个数据流能够保障有序交付，但多个数据流之间可能乱序，这意味着单个数据流的传输是按序的，然而多个数据流中接管方收到的程序可能与发送方的发送程序不同！ 疾速握手：QUIC提供0-RTT和1-RTT的连贯建设 应用TLS 1.3传输层平安协定：与更早的TLS版本相比，TLS 1.3有着很多长处，但应用它的最次要起因是其握手所破费的往返次数更低，从而能升高协定的提早。 妨碍以上，咱们介绍了很多QUIC的相比拟于TCP的长处，能够说这种协定相比拟于TCP的确要优良一些。 因为他是基于UDP的，并没有扭转UDP协定自身，只是做了一些加强，尽管能够避开中间设备僵化的问题，然而，在推广下面也不是齐全没有问题的。 首先，很多企业、运营商和组织对53端口（DNS）以外的UDP流量会进行拦挡或者限流，因为这些流量近来常被滥用于攻打。 特地是一些现有的UDP协定和实现易受放大攻打（amplification attack）威逼，攻击者能够管制无辜的主机向受害者投放发送大量的流量。 所以，基于UDP的QUIC协定的传输可能会受到屏蔽。 另外，因为UDP始终以来定位都是不牢靠连贯，所以有很多中间设备对于他的反对和优化水平并不高，所以，呈现丢包的可能性还是有的。。。 然而不论怎么样，HTTP/3.0的时代肯定会到来的，QUIC协定全面代替TCP的时代也会到来的，让咱们刮目相待吧。

文章不易，请关注公众号 毛毛虫的小小蜡笔，多多反对，谢谢 起源 在看RFC文档的时候，看到hop-by-hop这个词，有点纳闷，所以想着持续开掘下相干知识点。 含意hop是跳，hop-by-hop是逐跳的意思。end-to-end则是端到端。这两者都是http的头部字段。 详情 请查看：毛毛虫的小小蜡笔

TCPTCP 是面向连贯的、牢靠的、基于字节流的传输层通信协议 面向连贯：一对一连贯牢靠的：保障报文肯定可能达到接收端字节流：报文可被分为多个组报文格式seq：序列号，建设连贯时生成的随机数，每发送一次数据则自增，用于解决网络包乱序ack：确认应答号，发送端收到这个应答号后，可认为这个序号之前的数据曾经被失常接管，用于解决丢包ACK：该位为 1 时，确认应答号的字段变为无效SYN：该位为 1 时，示意心愿建设连贯FIN：该位为 1 时，示意今后不会再有数据发送，心愿断开连接三次握手前两次握手确保客户端胜利连贯第三次握手确保服务端胜利连贯 四次挥手第三步确保服务端实现本人未解决完的数据 TPC 和 UDP 的区别tcp牢靠，即发出请求胜利与否是可知的面向连贯，即客户端连贯到服务器必须建设起一个连贯绝对 udp 较慢udp不牢靠不面向连贯绝对 udp 较快

对于终端用户来说，表单提交的过程很不便，在某种程度上相当于输出数据，点击提交按钮。 然而，从工程的角度来看，它须要一种编码机制能力牢靠地将这些数据从客户端发送和接管到服务器端以进行后端解决。 应用 JavaScript 发送 form data，应用 PHP 作为服务器端接管，则 JavaScript 端须要应用 encodeURIComponent() 进行解决。 表单提交最罕用的 HTTP 办法是 POST。 然而，对于幂等的表单提交，咱们也能够应用 HTTP GET 办法。 并且，指定办法的形式是通过表单的办法属性。 对于应用 GET 办法的表单，整个表单数据作为查问字符串(query string)的一部分发送。 然而，如果咱们应用 POST 办法，那么它的数据将作为 HTTP 申请注释(body)的一部分发送。 而且，在后一种状况下，咱们还能够通过表单的enctype属性来指定数据的编码方式，该属性能够取两个值，别离是application/x-www-form-urlencoded 和 multipart/form-data。 HTML 表单的 enctype 属性的默认值为 application/x-www-form-urlencoded，因为它解决了数据齐全是文本的根本用例。 然而，如果咱们的用例波及反对文件数据，那么咱们将不得不用 multipart/form-data 的值笼罩它。 实质上，它将表单数据作为键值对发送，并由 & 字符分隔。 此外，相应的键和值用等号 (=) 分隔。 此外，所有保留字符和非字母数字字符都应用百分比编码进行编码。 看上面的代码： // url encode your stringvar string = encodeURIComponent('+'); // "%2B"// send it to your serverwindow.location = 'http://example.com/?string='+string; // http://example.com/?string=%2B

企业介绍该企业是一家集芯片设计、工艺研发、晶圆生产与测试、销售服务于一体的半导体存储器企业，为寰球提供先进的存储产品和解决方案，广泛应用于挪动通信、计算机、数据中心和生产电子畛域。我的项目背景数据是企业的重要资产，是企业数字化的根底和前提。在国企数字化转型的过程中，不仅要买通“数据孤岛”，还须要翻越数据品质和数据安全这两座“大山”，而数据治理就是连贯大山的桥梁。本我的项目的建设内容就是从数据接入、转换、利用各个阶段增强数据品质的管控，为团体数仓、数据分析、数据挖掘利用提供规范、牢靠的根底数据撑持。以后该企业数据资源波及7000-8000张数据库表，存储于不同的关系型数据库以及分布式数据库中，每天的增量数据在1-2T左右，在ETL过程中须要对数据的及时性、完整性和一致性进行校验。同时须要对相互有关联的业务数据进行业务规定校验，各式各样简单的业务规定逻辑须要依附业务骨干的工作积攒和教训反复推敲能力落地，单靠技术部门的投入难以达到最好的成果。 综上，该企业须要一款独立于业务零碎之外的数据品质治理平台，一方面满足技术部门长效的数据品质管控，另一方面可能造成业务精英为主、技术精英为辅的业务数据梳理体系。 我的项目痛点1、需反对多样化的数据起源以后业务数据存储在不同类型的数据库中，蕴含Oracle/Mysql/SQLServer/Postgresql/Hive/HDFS/Hbase/Kudu/Vertica等，所选平台须要具备多种数据源的接入机制，并可能基于后续的业务倒退，实用更多的数据起源。2、需反对繁简不一的规定配置在数据品质管控过程中，须要进行各种各样的质检规定配置，简略的如空值校验、字段类型校验、值域校验、及时性校验等，简单波及多表关联的逻辑公式校验、完整性校验、一致性校验等，所选平台须要反对多种规定的校验设置，同时还要便于技术能力较弱的业务精英进行操作。3、需反对海量数据的解决应答面对海量数据的质检，不仅是数据量大，同时还面临多个质检工作的并发。一方面须要在规定工夫内实现所有测验，另一方面给还须要及时将后果反馈给数据管理者。所选平台须要具备大数据量的解决能力、反对多个质检过程并发，同时还要思考后续数据量越来越大，接入的数据源越来越多的发展趋势，可能反对集群中节点的灵便扩大，满足长期的数据质检须要。建设内容数据品质治理平台次要用于解决业务零碎运行、数据仓库建设及数据治理过程中的数据品质问题。它以标准化的数据品质标准为根底，使用数据挖掘、数据分析、工作流、评分卡、可视化等技术帮忙组织建设数据品质管理体系，晋升数据的完整性、规范性、及时性、一致性、逻辑性，升高数据管理老本，缩小因数据不牢靠导致的决策偏差和损失。 零碎次要性能包含质量检查规定治理、绩效治理、工作流治理、品质剖析报表查问、品质报告等。我的项目建设架构图1、单点登录为满足公司外部的通过对立身份认证平台进行数据品质平台的登录，实现了与认证平台的单点登录集成。2、品质问题实现短信预警数据品质平台反对依照配置的质检计划主动的执行质检，质检后果会主动的通过邮件或者短信发送到相干责任人，揭示技术人员及时的解决品质问题。3、反对多种大数据平台数据源的质检平台除了反对常见的关系型数据库数据进行质检外，还反对Hive/HDFS/Hbase/Kudu/Vertica等多种大数据库的数据源接入，可能满足公司后续的业务倒退，实用丰盛的数据类型。我的项目价值该企业数据品质治理平台的建设，满足了公司数据品质管控的需要，实现了数据质量检查的主动执行和问题数据短信预警，大大的晋升了业务数据的品质，为公司数仓、数据分析、数据挖掘利用提供规范、牢靠的根底数据撑持。客户对于我的项目整体建设成绩十分称心，通过产品的利用，使各业务条线的数据品质问题失去无效管控，简化技术人员的数据品质问题核查的工作难度，同时极大的晋升了客户的工作效率。 1）数据品质治理平台提供了可视化的页面就能实现数据质量检查工作，大大降低了数据质检的技术门槛，不仅仅只靠公司数据部门的技术人员来晋升数据品质，当初也将业务部门的人员也参加到数据品质晋升工作中，造成业务精英为主、技术精英为辅的业务数据梳理体系。2）数据品质的质检后果实现了短信主动预警，揭示技术人员及时的解决品质问题，晋升了技术部门的数据品质问题管理效率。3）随着公司业务数据一直增大，大数据平台的利用不断深入，数据品质平台反对多种基于Hadoop的数据源的接入进行质检，为公司业务的倒退和品质治理奠定了根底。 以上内容均来自《数据治理精选案例集》，局部目录如下，此书笼罩13个行业数据治理策略深度拆解，60+政企数据治理标杆案例，300+利用场景全面笼罩，1000+一线项目管理教训，助您破解数据治理难题。登录亿信华辰官网，增加客服企业微信，回复“案例集”即可收费支付纸质版。

我的项目背景贷后治理策略往科学化和信息化方向倒退，从业务价值和用户价值登程，搭建贷后查看渎职治理及粮棉油库存巡逻零碎，嵌入贷款治理流程，对渎职查看实现状况造成刚性管制，督促经营行必须做到“真去、真查”，促成转变工作形式，造就客户经理贷后查看留痕习惯，转变工作形式，盲目自发做好现场查看，实时、主观反映贷后渎职及库存巡逻状况，可能通过图片、视频主观反映现场状况。业务价值：将贷后渎职治理纳入贷款治理全流程，晋升贷后查看工作质效，促成合规操作，推动渎职免责治理用户价值：优化业务流程；进步工作效率；与现有零碎比拟进步了稳定性和可用性我的项目痛点1、贷后管理水平单薄长期以来，各级行贷后管理工作不同水平地存在制度落实不到位、贷后查看流于形式、查看内容不够全面等问题，无奈及时发现和处理潜在危险。2、目前省行自建零碎无奈满足业务需要大部分省行采纳福建省行研发的贷后查看零碎，零碎存在兼容性差、权限无奈精准管制、无奈涵盖所有贷后查看业务等问题，同时省行零碎无奈跟信贷零碎建立联系，须要业务人员别离在两个零碎解决。3、大量手工录入工作业务人员在发展贷后查看时，需从贷款客户获取大量信息录入零碎，工作沉重，冀望能退出一些新兴的互联网技术如OCR辨认、语音转写等，以达到给基层人员减轻负担的指标。建设内容贷后渎职及库存巡逻零碎涵盖两个体系、两级利用。 两个体系：建设标准规范体系和平安标准体系，具体包含数据标准规范、接口标准标准的定义，以及利用平安、数据安全等建设。两级利用：零碎分为治理端利用和挪动端利用，治理端次要面向银行管理人员提供应用服务；挪动端次要面向基层行业务人员提供应用服务。1、开发贷后渎职模块在粮棉油库存巡逻零碎上开发贷后渎职模块，满足贷后渎职查看工作的发展。次要性能包含：贷后查看模板保护、发动贷后查看、主动生成查看项、挪动端信息采集、欠缺贷后查看、监控督导等；2、库存巡逻模块优化依据我行需要在一期根底上进行客户化革新。同时须要粮棉油库存巡逻零碎产品全面满足我行在业务、技术、施行、培训、服务及其它方面的要求并晋升零碎易用性；3、买通内部零碎跟CM2006零碎建设接口，从CM2006零碎接入机构、员工、客户、合同、我的项目等根底数据，根据这些信息对客户发展贷后查看，将查看后果通过接口发送到CM2006零碎；跟电子影像平台建设接口，零碎采集的图片、视频等文件存在电子影像平台，与CM2006零碎交互影像内容通过电子影像平台直达；4、开发贷后渎职APP基于库存巡逻一期专用设备上开发贷后渎职模块，发展信息采集工作，与治理端数据实时同步，同时采集的音视频文件需减少地理位置和工夫程度，一方面防止信息泄露，另一方面也解决了业务人员“是否到现场”的工作考核断定。我的项目价值1、实现了贷后渎职查看模块，跟原有零碎相比，实现了模板与业务的主动匹配、信息采集的实时同步、个性化权限管制、与CM2006零碎数据共享等性能，从而加重了基层业务人员的累赘；2、使用RFID辨认、百度地图鹰眼轨迹、OCR图像识别等互联网技术为客户打造“互联网+”现场巡逻，晋升了贷后渎职检查和库存巡逻的技术含量，实现了现场巡逻的主动解决；3、零碎提供了丰盛的剖析性能，便当了治理行监控督导基层行业务人员工作状况。 以上内容均来自《数据治理精选案例集》，局部目录如下，此书笼罩13个行业数据治理策略深度拆解，60+政企数据治理标杆案例，300+利用场景全面笼罩，1000+一线项目管理教训，助您破解数据治理难题。登录亿信华辰官网，增加客服企业微信，回复“案例集”即可收费支付纸质版。

　劣势总结基于SCRM零碎交融社交媒体数据的特点——用户与品牌互利的角度 以社交软件为媒介，在适当的工夫以客户脍炙人口的形式进行品牌宣传，进步品牌触达的效率。 全渠道获客，拓展新的客户群体，通过SCRM的数据监控和追踪挖掘更多的潜在客户。 站在用户与品牌互利的角度：SCRM零碎交融社交媒体数据的特点和劣势 SCRM零碎通过社交平台作为媒介，可能抉择在最合适的工夫用脍炙人口的形式向客户宣传本人的品牌，从而最大水平上进步品牌的触达率。 SCRM零碎的数据监控和追踪性能可能全渠道获客，可能帮忙咱们开掘更多的潜在客户，拓展新的客户群体。 SCRM零碎不仅可能利用客户应用最频繁的社交软件平台与客户进行沟通交流，而且能及时取得客户的反馈和评估以及跟踪客户的行为等，为了可能更全面深度地理解客户的需要，SCRM零碎还有能够生成残缺全面的全息用户画像性能，从而实现更个性化，更加疾速的客户服务响应；为了更好的建立优质良好的品牌形象流传品牌美誉，SCRM零碎还能在实习客户服务响应的同时还可能挖掘出品牌拥护者的价值，缩短与客户的间隔，减少与客户的接触和深入与客户的分割。 品牌利用SCRM零碎通过与客户对话实现个性化互动，关键词抓取等模式最快速度理解到最新的行业动态和客户感知，为企业产品和服务的更新提供有价值的参考，从而更好的优化产品和服务，有利于企业长期倒退策略更无效的急功近利，流传企业品牌价值。 SCRM零碎能够帮忙企业在真正的意义上实现品牌和用户间隔的双向奔赴。 一方面，SCRM零碎可能在帮忙企业发现和开掘更多更有价值的线索的同时优化客户的用户体验，让品牌与用户的良好关系失去维持，从而大大缩短和进步了用户的生命周期和用户价值，充沛展现和流传了品牌的良好的价值观和品牌形象，能更好的吸引客户，让客户自愿地去理解品牌并且参加品牌流动中。 另一方面，SCRM零碎可能利用实时的用户数据，随时更新理解消费者行为与消费者对产品和服务的反馈等其余信息，最大水平上帮忙品牌更加全方位、深度的理解用户，让产品更快的实现降级转化。

前言最后的HTTP协定是无状态的，兴许在设计者Tim Berners-Lee就应该是无状态的，自身只是为扩散在网络上的材料建设连贯而已，在同一个连贯中，两个执行胜利的申请之间并没有什么分割。随着万维网的倒退, 呈现了各种各样的网站，缓缓的有些网站须要辨认用户的身份，一个十分典型的场景就是网购，在大型超市中买货色，超市会为客户提供购物车，顾客在不同的商品区购物放在购物车，最终对立结账，然而因为HTTP的无状态，咱们无奈在线上实现购物车的成果，由此咱们引出Cookie，Cookie的呈现让HTTP有了状态，然而有了Cookie还不够，咱们还心愿对不同的用户实现不同的权限管制，由此咱们引出HTTP的认证。随着网络的一直倒退，服务器的压力在一直的减少，单台机器缓缓无奈应答一劳永逸的访问量，由此咱们引出了代理服务器。 Cookie概述HTTP Cookie是服务器发送到用户浏览器并保留在本地的一小块数据，它会在浏览器下次向同一服务器再发动申请时并发送到服务器上，用来告知服务端两个申请来自同一个浏览器，放弃用户状态等。 一般来说，Cookie次要用于以下三个方面: 会话状态治理(如用户登录状态、购物车等其余须要记录的信息)浏览器行为跟踪(如跟踪剖析用户行为等)在过来因为没有其余适合的存储方法，Cookie一度用于客户端数据存储，然而随着古代浏览器的倒退，浏览器开始反对各种各样的存储形式，新的浏览器API曾经容许开发者间接将数据存储到本地，如应用 Web storage API 或 IndexedDB, 有了更多抉择，Cooke慢慢的就被淘汰，浏览器反对更多的存储形式并不是Cookie惟一被淘汰的理由，还有一个就是性能问题，因为服务器指定Cookie之后，浏览器的每次申请都会携带Cookie数据，会带来额定的性能开销(尤其是在挪动环境下) 当服务器收到HTTP的申请时，服务器能够在响应头外面增加一个Set-Cookie选项，一个简略的Cookie可能像上面这样: Set-Cookie: <cookie名>=<cookie值>浏览器收到响应后通常会保留下Cookie，之后对该服务器每一个申请中都通过Cookie申请头部将Cookie信息发送给服务器。另外,Cookie的过期工夫、域、门路、有效期、实用站点都能够依据须要来指定。 然而Cookie也不能永远保留，由此咱们就引出了定义Cookie的生命周期, Cookie的生命周期有以下两种 会话期Cookie，这是最简略的Cookie，浏览器敞开之后会被主动删除，会话期Cookie不须要指定过期工夫(Expires)或者有效期(Max-Age).然而值得注意的是，有些浏览器提供了会话复原性能，这种状况下，即便敞开了浏览器，会话器Cookie也会被保留下来，就如同浏览器素来没有敞开一样，这就会导致Cookie的生命周期无限期缩短。持久性Cookie的生命周期取决于过期工夫(Expires) 或有效期(Max-Age)指定的一段时间。认证概述作为一个后端仔，常常和postman打交道，如果你留神的话，会发现postman除了申请头，申请参数、申请体。还有一个Authorization。如下图所示: 事实上认证也是HTTP协定规范的一部分，在RFC-7235引入，该草案定义了一个HTTP身份验证框架，服务器能够用来针对客户端的申请发送质询信息，客户端则能够用来提供身份验证凭证。质询与应答的工作流程如下: 服务端向客户端返回401(未受权)，并在WWW-Authenticate首部提供如何进行验证的信息，其中至多蕴含有一种质询形式。之后客户端能够在新的申请中增加Authorization首部字段进行验证，字段值为身份验证凭证信息。 下面咱们形容的RFC-7235咱们能够了解为一个规范，在这个规范之下，有多种计划。IANA保护了一系列验证计划，除此之外还有其余的验证计划由虚拟主机服务提供，例如Amazon AWS。常见的验证计划如下： Basic (RFC 7617 引入 base64编码凭证)Bearer(RFC 6750 引入 bearer领票通过Auth 2.0爱护资源)Digest(RFC 7616 引入 只有md5散列在Firefox中反对, 有bug，bug编号为472823用于SHA加密反对)HOBA(由RFC 7486(目前还是草案)，HTTP Origin-Bound认证，基于数字签名)代理服务器概述下面咱们提到了随着万维网的一直倒退，单台计算机慢慢的无奈满足一劳永逸的访问量，简略而粗犷的解决这个问题的策略就是再加一台计算机，除此之外开发者们还发现服务器上的一些资源是动态的或者是很少产生扭转的，将这类资源独自放到一台服务器上也能晋升零碎的响应能力，于是这里呈现了代理服务器。存储动态资源，同时做负载平衡，由代理服务器将申请散发到集群中的服务器上。 说到这里，你肯定想起了Nginx吧。 参考资料火狐开发者文档 https://developer.mozilla.org...bug编号472823 https://bugzilla.mozilla.org/...

如何基于Promise设计简略的申请/响应拦截器面试官问你，如何能力设计出像 Axios 这样牛皮的申请和响应拦截器? 能不能简略手写其中的原理 // xhr适配器 var dispatch = (config) => { return new Promise((resolve, reject) => { setTimeout(() => { // 模仿xhr 后果响应值 resolve('cpp', config); }, 1000); });};// 申请function request(config) { var promise; var interceptor = { request: [ (config) => { console.log(config, 'request config'); return config; }, (err) => { console.log(err); }, ], response: [ (res) => { console.log(res, 'response res'); return res; }, (err) => { console.log(err); }, ], }; var chain = [dispatch, null]; chain.unshift(...interceptor.request); // 留神chain数组的前后程序 chain = chain.concat(interceptor.response); promise = Promise.resolve(config); while (chain.length) { promise = promise.then(chain.shift(), chain.shift()); } return promise;}request({ name: 'CPP REQUEST', url: 'api/get/data',}).then((res) => { console.log(res, 'LAST RES');});// 打印后果// request config// response res// cpp LAST RES之前始终不是特地能了解拦截器的外围实现原理，也就是上面这几段代码 ...

vivo 互联网服务器团队- Wei Ling本文次要讲述的是如何依据公司网络架构和业务特点，锁定失常申请被误判为跨域的起因并解决。 一、问题形容某一个业务后盾在表单提交的时候，报跨域谬误，具体如下图： 从图中可看出，报错起因为HTTP申请发送失败，由此，需先理解HTTP申请残缺链路是什么。 HTTP申请个别通过3个关卡，别离为DNS、Nginx、Web服务器，具体流程如下图： 浏览器发送申请首先达到当地运营商DNS服务器，通过域名解析获取申请 IP 地址浏览器获取 IP 地址后，发送HTTP申请达到Nginx，由Nginx反向代理到Web服务端最初，由web服务端返回相应的资源 理解HTTP根本申请链路后，联合问题，进行初步考察，发现此form表单是application/json格局的post提交。同时，此业务零碎采纳了前后端拆散的架构形式(页面域名和后盾服务域名不同 ), 并且在Nginx曾经配置跨域解决方案。基于此，咱们进行剖析。 二、问题排查步骤第一步：自测定位 既然是form表单，咱们采纳控制变量法，尝试对每一个字段进行批改后提交测试。在屡次试验后，锁定表单中的moduleExport 字段的变动会导致这个问题。 思考到moduleExport字段在业务上是一段JS代码，咱们尝试对这段JS代码进行删除/批改，发现：当字段moduleExport中的这段js代码足够小的时候，问题隐没。 基于上述发现，咱们第一个猜测是：会不会是HTTP响应方的申请body大小限度导致了这个问题。 第二步：排查 HTTP 申请 body 限度 因为采纳前后端拆散，实在的申请是由 XXX.XXX.XXX 这个内网域名代表的服务进行响应的。而内网域名的响应链如下： 那么实践上，如果是HTTP申请body的限度，则可能产生在 LVS 层或者Nginx层或者Tomcat。咱们一步步排查： 首先排查LVS层。若LVS层故障，则会呈现网关异样的问题，返回码会为502。故此，通过抓包查看返回码，从下图可看出，返回码为418，故而排除LVS异样的可能 其次排查Nginx 层。Nginx层的HTTP配置如下: 咱们看到，在Nginx层，最大反对的HTTP申请body为50m， 而咱们这次事变的form申请表单，大概在2M， 远小于限度， 所以：不是Nginx 层HTTP申请body的限度造成的。 而后排查 Tomcat 层，查看 Tomcat 配置： 咱们发现， Tomcat 对于最大post申请的size限度是-1， 语义上示意为无限度，所以： 不是 Tomcat 层HTTP申请body的限度造成的。 综上，咱们能够认为：此次问题和HTTP申请body的大小限度无关。 那么问题来了，如果不是这两层导致的，那么还会有别的因素或者别的网络层导致的吗？ 第三步：集思广益 咱们把相干的运维方拉到了一个群外面进行探讨，探讨分两个阶段 【第一阶段】运维方同学发现 Tomcat 是应用容器进行部署的，而容器和nginx层两头，存在一个容器自带的nameserver层——ingress。咱们查看ingress的相干配置后，发现其对于HTTP申请body的大小限度为3072m。排除是ingress的起因。 【第二阶段】平安方同学示意，公司为了避免XSS攻打，会对于所有后盾申请，都进行XSS攻打的校验，如果校验不通过，会报跨域谬误。 也就是说，实践上残缺的网络层调用链如下图： 并且从WAF的工作机制和问题表象上来看，很有可能是WAF层的起因。 第四步：WAF 排查 ...

个别我写的文章行文格调大抵都是，先从总体上阐述，而后再深刻到细节中。 有一天，我发现我父亲正在读一本对于大脑的书， 寻找如何让计算机领有直觉，可能像大脑一样倒退出关系的线索，计算机在逻辑组织和解决上做得很好, 但随机的关联不行，咱们探讨了这一点，而后我做作业去了，但这个想法随同着我，计算机是能够变得更加弱小的，如果计算机能被编程来关联，本没有被关联的信息，极其点说，世界能够被看作时齐全由连结组成的，咱们把词典设想成一个意义的仓库，它只是在用别的词来定义一个词，真的没什么别的含意了，咱们的大脑由数以亿级的神经元，直到神经元之间建设连贯之前，大脑都不领有常识，重要的是连贯。 --- Tim Berners-Lee（蒂姆•伯纳斯•李） 创造了万维网、第一个网络浏览器、以及容许网络扩大的根本协定和算法 由互联网到万维网在TCP、UDP协定之后，两台位于不同地区的计算机就能够进行通信了, 这是个了不起的个性，我在上海跟在河南的父母发消息，可比现代六百里加急还要快，然而在应用层的协定、万维网到来之前，互联网还和普通人比拟边远，像是一颗刚发了芽的种子，谁也不会想到在不久的未来，整个世界都将笼罩在它的荫凉之下。 TCP协定发表于1981年，即便传输层提供了牢靠传输服务，下面悬浮的利用也比拟少，在我国也就用于政府、科研单位疾速的传递信息，然而传递信息的形式仿佛也比拟繁多，信息之间没有建设起连贯，这一点能够从中国科学院高能物理研究所的网络倒退中大抵看到，1986年以长途电话线为介质，实现了高能所与西欧核心CERN之间的电子邮件的传输，学者们之间的通信材料，没被连接起来。你对我的钻研材料比拟感兴趣，你发封邮件给我，而后我把邮件发给你。仿佛过后的人们将互联网当成了新时代的信鸽，用来传递一些要害的信息。直到万维网的呈现，通过超链接这种媒介，互联网中各个孤立的信息才被建设强连贯，实现从一个信息跳转到另一个信息。 写到这里想起我大学的时候，在学习《计算机网络》这门课程的时候，看到万维网这一节，说实话过后我看的似懂非懂的，我不晓得什么叫万维网，即便我关上浏览器输出网址，浏览网站信息曾经很纯熟了，但我也没意识到我过后用的是万维网，我认为那就是互联网，兴许在我眼里点击网站链接跳到另一个网站是以一个天经地义的操纵，过后我的计算机网络学的真的是一团糟，我前面对网络认知的加深全是写程序的时候遇到问题，而后去查资料。悄悄的吐槽一下，我大学的时候的教材翻译是着实有些拗口，我感觉我读不懂也失常，介绍万维网是这么介绍的: 万维网WWW(World Wide Web)并非某种非凡的计算机网络，万维网是一个大规模的、联机式的信息储藏所。简称为WEB。过后的我没有把万维网和日常浏览的网站分割起来，(这也跟我当初听课听不懂，前面就放弃了有关系,其实前面有讲到浏览器，只不过用的形容语让我无论如何都没有跟我日常浏览的网站分割起来)，所以我只看懂了前半句：万维网WWW(World Wide Web)并非某种非凡的计算机网络，万维网是一个大规模是。信息储藏所我是看不大懂的，更不必提前面的超文本了、URL之类的了。 我这里想引入另一种视角来介绍万维网，从 Tim Berners-Lee的设计万维网的缘起谈起，即为信息建设连贯。Tim Berners Lee进入欧洲原子核研究所，过后的科学家迫切需要一个不便疾速的平台来帮忙他们近程沟通替换数据，基于这个问题，Tim Berners Lee 设计了万维网，我猜测最后浏览器拜访的网址寄存的就是原子核研究所的钻研材料(查了很久，这方面的材料比拟难找，有工夫会尝试写一下Web简史)，各个文档还是孤立的，那为各个文档建设连贯，面临的问题有哪些呢? 怎么标记散布在互联网上的万维网文档？用怎么的协定来实现万维网上各个文档上的连贯?怎么实现在不同的计算机上实现对立的显示成果呢？为了解决第一个问题，万维网应用URL来标识万维网上的各种文档(网页)，并使每一个文档在整个互联网的范畴内具备惟一的标识符(URL)。粗略的说URL=IP:端口/门路。第二个问题就引出了咱们的HTTP协定, 第三个问题的答案就是HTML，对立格局、语法。 由万维网到HTTP协定HTTP协定概述HTTP译为超文本传送协定，这个超文本能够了解为不止是文本，能够传送图像、视频，最后只是能是动态的。HTTP协定规定了浏览器(客户端过程)怎么向万维网服务器申请万维网文档，以及服务器怎么把文档传送给浏览器。 下面这张图片来自火狐开发者文档。 从档次的角度来讲，HTTP协定是面向事务的，面向事务的意思是一系列信息替换要么全副胜利，只有有一次替换失败就全副失败。每个网站都有一个服务器过程一直的监听TCP的端口80, 以便发现是否有浏览器(或其余客户端)向它收回连贯建设申请，一旦监听到连贯建设申请并建设了TCP连贯之后，浏览器就向服务器发动HTTP申请，服务器依据申请响应对应的资源。最初,TCP链接就被开释了。在浏览器和服务器之间的申请和响应的交互必须依照规定的格局和遵循肯定的规定，这些规定和格局就是HTTP协定。 它是在 Web 上进行数据交换的根底，是一种 client-server 协定，也就是说，申请通常是由像浏览器这样的接受方发动的。一个残缺的Web文档通常是由不同的子文档拼接而成的，像是文本、布局形容、图片、视频、脚本等等 HTTP协定因为运输层选取的是面向连贯的TCP协定，保障了数据的牢靠传输，然而，HTTP协定是自身是无连贯的，这就是说，尽管HTTP应用了TCP连贯，但通信的单方在替换HTTP报文之前不须要先建设HTTP连贯。 HTTP在利用的晚期阶段非常简单，简略的甚至没有版本号， 起初它的版本号被定位在0.9以辨别起初的版本。HTTP/0.9极其简略: 申请由单行指令形成, 以惟一可用办法GET结尾，其后跟指标资源的： GET /mypage.html响应也极其简略: 只蕴含响应文档自身。 <HTML>这是一个非常简单的HTML页面</HTML>起初被称为HTTP/0.9, 有时也被叫做单行(one-line)协定，跟起初的版本不同，HTTP/0.9 的响应内容并不蕴含HTTP头，这意味着只有HTML文件能够传送，无奈传输其余类型的文件；也没有状态码或错误代码：一旦呈现问题，一个非凡的蕴含问题形容信息的HTML文件将被发回，供人们查看。 随着万维网的一直倒退，浏览器和服务器迅速扩大其用处更广, HTTP/0.9版本就有点跟不上时代的倒退了, 随后就推出了HTTP/1.0版本： 协定版本信息当初会随着每个申请发送（HTTP/1.0被追加到了GET行）。状态码会在响应开始时发送，使浏览器能理解申请执行胜利或失败，并相应调整行为（如更新或应用本地缓存）。引入了HTTP头的概念，无论是对于申请还是响应，容许传输元数据，使协定变得非常灵活，更具扩展性。在新HTTP头的帮忙下，具备了传输除纯文本HTML文件以外其余类型文档的能力（凭借Content-Type头）当初的浏览器通过开发者工具能够分明的看到申请和响应报文: 尽管HTTP/2.0版本曾经推出来了, 然而目前国内广泛应用的还是HTTP/1.1协定, 那HTTP 1.1 版本绝对于HTTP/1.0版本减少了什么呢？ 在HTTP1.0版本中，在客户端(通常指浏览器)与服务器可能交互(客户都按发动申请, 服务器返回响应)之前, 必须在这两者之间建设一个TCP链接，关上一个TCP连贯须要屡次往返交互音讯(因而耗时)。HTTP/1.0默认为每一对HTTP/响应都关上一个独自的TCP连贯。 当间断发动多个申请时，这种模式比多个申请共享一个TCP链接更低效。 连贯治理是一个HTTP的要害话题, 在HTTP/1.1里有多种模型: 短连贯、长连贯, HTTP 流水线。 ...

一、 并发● HTTP1.1形式：建设多个TCP连贯，一个TCP解决一个HTTP申请。长处：每个TCP之间齐全隔离，一个TCP解决一个申请不存在队头阻塞问题，一个TCP产生故障不影响其余TCP解决。毛病：1、 实现老本高。TCP是由操作系统内核实现的，如果通过多线程实现并发，并发线程数 不能太多，否则线程间切换老本会以指数级回升；如果通过异步、非阻塞socket实现并发，开发效率又太低。2、 每个TCP连贯与TLS回话都叠加了2-3个RTT的建链老本，减少了提早。3、 TCP连贯有一个防止出现阻塞的慢启动流程，会对每一个TCP连贯都产生加速成果。4、 浏览器和服务器都会做相应的TCP连贯限度，不能无限度的建设连贯。 ● HTTP2形式：多路复用，有序发送HTTP申请。长处： 同域名下所有的通信都在单个连贯上实现，该连贯能够承载任意数量的双向数据流。能够实现全速传输，新开一个TCP连贯，传输速度须要缓缓晋升。毛病： 1、 HTTP2协定是基于TCP有序字节流实现，应用层的多路复用不能做到无序并发，在丢包时会呈现队头阻塞问题。 2、 当网络忙碌时，会减少丢包的概率，多路复用受到很大的限度，甚至效率可能还不迭HTTP1.1。 3、 后面两点都会呈现队头阻塞问题，其基本原来还是在于TCP协定自身不具备并发解决的能力，多路复用只是解决了HTTP并发的传输，然而最终的解决还是由单个的TCP有序解决申请，TCP在单位工夫里只能解决某一个申请，其中某一个申请产生异样都将影响到后续的申请。● HTTP3形式：有序的QUIC Stream。长处：1、 QUIC基于UDP，原生反对并发解决。与HTTP2一样，同一条QUIC连贯能够创立多个stream，来承载多个HTTP申请，然而QUIC连贯上的多个stream之间没有依赖，两头的某一个申请呈现丢包不会影响前面的stream。2、 在挪动端的良好反对，TCP是基于端口和IP去辨认连贯，在来回切换wifi时这种形式给用户的体验不是很敌对。QUIC是通过ID的形式去辨认一个连贯，网络环境发生变化，只有ID不变，就能迅速重连。二、 建连● 1RTT掂量网络建链的罕用指标Round-Trip Time，RTT蕴含三局部：往返流传时延、网络设备内排队时延、应用程序数据处理时延● TLS连贯过程TLSv1.2 握手过程根本都是须要四次，也就是须要通过 2-RTT 能力实现握手，而后能力发送申请，而 TLSv1.3 只须要 1-RTT 就能实现 TLS 握手。● HTTP1.1/HTTP2HTTP1.1与HTTP2连贯过程统一，须要三次握手建设TCP连贯，耗费1.5RTT。如果是HTTPS，那么还须要减少SSL/TLS的2个RTT。开启TCP Fast open，且TLS是1.3是能够同时进行握手操作的。 ● HTTP3HTTP3建连能够辨别为两种，首次连贯和非首次连贯。首次连贯客户端和服务端要应用1RTT进行密钥协商和数据传输过程。并且服务端会传递一个config包到客户端，外面蕴含服务端的公钥和配置，客户端会存储这个config，后续（非首次）连贯能够间接应用，从而跳过1RTT，间接进行数据交互。config有工夫期限，生效之后依然须要进行1RTT密钥替换。 三、 连贯迁徙TCPTCP协定应用的是五元组了标识一条连贯，并且判断起唯一性。然而咱们从4G环境切换到wifi环境时，手机的IP地址会发生变化，这时必须创立新的TCP连贯能力进行数据传输。QUICQUIC协定摒弃了五元组的形式，应用64维随机数作为连贯ID。网络切换不会导致ID变动，连贯仍旧可用，进步了业务层的体验感。 参考文章：https://blog.cloudflare.com/h...https://baijiahao.baidu.com/s...

在大数据时代背景下，随着政务、社会、数字经济减速倒退，企业数字化转型深刻浸透，企业累计数据资产增多，爱护数据安全成为重中之重。 数据安全始终以来都是vika维格表的最高准则。不久前，vika维格从技术、治理两大方面来对本身的信息爱护、平安审计、通信窃密等近 300 项评审内容进行标准和欠缺，最终经由国家信息安全监管部门进行的监督、查看、认证，胜利取得了「等保三级」认证。 「等保三级」是什么？ 全称「国家信息安全等级爱护三级认证」，是国家对非银行机构的最高级认证，属于「监管级别」。由国家信息安全监管部门进行监督、查看，认证。认证测评内容别离涵盖 5 个等级爱护平安技术要求和 5 个平安治理要求，共波及测评分类 73 类，要求非常严格。 技术上：物理平安、网络安全、主机平安、利用平安、数据安全及备份复原等。 治理上：平安管理制度、平安管理机构、人员平安治理、零碎建设治理、零碎运维治理等。 vika维格表也是市面上极少数有资格申请也有能力通过「等保三级」认证的 SaaS 软件之一。 vika领有国内权威的平安认证、成熟的信息安全管理体系、软件全生命周期平安保障以及全天候平安应急响应，来看看vika是如何守护你的数据安全的～ 企业级私密明码信息管理确保账户平安账户登录反对多因素身份认证。不仅如此，vika维格表还反对集成飞书、企业微信、钉钉、微信、QQ 等支流 IM 工具软件，让用户领会到「领有这个vika维格表帐号的人，只能也只有我本人」。 任何官网人员均无奈间接拜访数据信息，确保用户数据隐衷平安。 在vika维格表的利用中，所有利用内的数据受权，均通过 Vault 密钥钱包进行平安验证治理，也就是说，其余利用无奈随便获取你的重要信息。 加密传输与存储用户数据有保障数据传输环节的平安，由数字证书治理和密钥算法来保障。在vika维格表中，数据是离散式存储的，存储的数据内容的可读性为 0。 加密数据通过 HTTPS/SSL/TLS 协定，配置 CA 证书，进行加密传输，具备身份双向验证性能。2048 位 RSA 密钥应用 KMS 治理密钥，密钥定期轮换，一次一密高平安保障。 高可用、多正本冗余存储与定时全量备份，保证数据可用性、完整性与数据安全。 全方位全天候的平安进攻继续稳固的服务vika维格表领有顶尖的技术团队，全天候为你的数据安全保驾护航，保障业务间断不间断。 多区跨云容器云运维架构，vika维格表每年投入大量资源建设平安运维基础设施，以确保你的数据安全。 两地三核心备份，保障劫难时疾速复原，牢牢把握「数据安全生命线」。 技术团队背景来自金山软件、字节跳动、阿里巴巴、金蝶国内、猎豹挪动等科技大厂。领有顶级技术实力，业余平安团队为你的数据安全保驾护航。 7×24 小时的平安应急响应，随时随地提供产品的平安爱护。 专有云部署独家定制你的专属vika维格表思考到客户的平安需要，在基于「多层交融技术」架构的根底上，vika还反对容器化的专有云部署。 你能够在你的数据库、服务器，独立部署vika专有云，同时随着vika维格表版本的一直降级，你的专有云也会继续降级。 专有云以极低成本满足你对数据安全的要求，最低只需 1 台服务器即可将你的数据把握在本人手上。 在 vika维格表取得「等保三级」认证后，会时时刻刻处于国家网络管理机构的监管之下。同时，vika曾经做好了万全筹备，以应答可能呈现的任何信息安全问题。 vika维格表作为新一代的数据生产力平台，在帮忙用户更便捷地治理数据，并保障数据安全，爱护用户隐衷。 如果你在寻找平安、高效的数字化落地计划，点击这里预约收费演示。或者扫描下方二维码，增加vika维格数字化参谋，理解更多。 一个彩蛋，流动预报登登登～vikaby 送你一个收费自我增值和晋升认知的机会。 4 月 28 号，也就是今天，vika维格课堂 x 风变科技特邀领有多年数字化落地教训的vika教育经营负责人和风变科技的策略单干专家，联合推出「数字战「疫」，生产力的改革与超过」直播流动，为你解读晋升数字化生产力的神秘，分享最新的教育工具。 ...

网络分层构造计算机网络体系大抵分为三种，OSI七层模型、TCP/IP四层模型和五层模型。 OSI七层模型OSI七层模型：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。 TCP/IP五层模型TCP/IP五层模型：应用层、传输层、网络层、数据链路层、物理层。 应用层：为应用程序提供交互服务。在互联网中的应用层协定很多，如域名零碎DNS、HTTP协定、SMTP协定等。传输层：负责向两台主机过程之间的通信提供数据传输服务。传输层的协定次要有传输控制协议TCP和用户数据协定UDP。网络层：抉择适合的路由和替换结点，确保数据及时传送。次要包含IP协定。数据链路层：在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。物理层：实现相邻节点间比特流的通明传输，尽可能屏蔽传输介质和物理设施的差别。TCP/IP四层模型TCP/IP五层模型：应用层、传输层、网络层、数据链路层 应用层：为应用程序提供交互服务。在互联网中的应用层协定很多，如域名零碎DNS、HTTP协定、SMTP协定等。传输层：负责向两台主机过程之间的通信提供数据传输服务。传输层的协定次要有传输控制协议TCP和用户数据协定UDP。网络层：抉择适合的路由和替换结点，确保数据及时传送。次要包含IP协定。数据链路层：在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。htttp连贯三次握手第一次握手：客户端向服务端发动建设连贯申请，客户端会随机生成一个起始序列号x，客户端向服务端发送的字段中蕴含标记位SYN=1，序列号seq=x。第一次握手前客户端的状态为CLOSE，第一次握手后客户端的状态为SYN-SENT。此时服务端的状态为LISTEN。第二次握手：服务端在收到客户端发来的报文后，会随机生成一个服务端的起始序列号y，而后给客户端回复一段报文，其中包含标记位SYN=1，ACK=1，序列号seq=y，确认号ack=x+1。第二次握手前服务端的状态为LISTEN，第二次握手后服务端的状态为SYN-RCVD，此时客户端的状态为SYN-SENT。（其中SYN=1示意要和客户端建设一个连贯，ACK=1示意确认序号无效）第三次握手：客户端收到服务端发来的报文后，会再向服务端发送报文，其中蕴含标记位ACK=1，序列号seq=x+1，确认号ack=y+1。第三次握手前客户端的状态为SYN-SENT，第三次握手后客户端和服务端的状态都为ESTABLISHED。此时连贯建设实现。两次握手能够吗？第三次握手次要为了避免已生效的连贯申请报文段忽然又传输到了服务端，导致产生问题。 比方客户端A收回连贯申请，可能因为网络阻塞起因，A没有收到确认报文，于是A再重传一次连贯申请。连贯胜利，期待数据传输结束后，就开释了连贯。而后A收回的第一个连贯申请等到连贯开释当前的某个工夫才达到服务端B，此时B误认为A又收回一次新的连贯申请，于是就向A收回确认报文段。如果不采纳三次握手，只有B收回确认，就建设新的连贯了，此时A不会响应B的确认且不发送数据，则B始终期待A发送数据，浪费资源。四次挥手A的利用过程先向其TCP收回连贯开释报文段（FIN=1，seq=u），并进行再发送数据，被动敞开TCP连贯，进入FIN-WAIT-1（终止期待1）状态，期待B的确认。B收到连贯开释报文段后即收回确认报文段（ACK=1，ack=u+1，seq=v），B进入CLOSE-WAIT（敞开期待）状态，此时的TCP处于半敞开状态，A到B的连贯开释。A收到B的确认后，进入FIN-WAIT-2（终止期待2）状态，期待B收回的连贯开释报文段。B发送完数据，就会收回连贯开释报文段（FIN=1，ACK=1，seq=w，ack=u+1），B进入LAST-ACK（最初确认）状态，期待A的确认。A收到B的连贯开释报文段后，对此收回确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（工夫期待）状态。此时TCP未开释掉，须要通过工夫期待计时器设置的工夫2MSL（最大报文段生存工夫）后，A才进入CLOSED状态。B收到A收回的确认报文段后敞开连贯，若没收到A收回的确认报文段，B就会重传连贯开释报文段。第四次挥手为什么要期待2MSL？保障A发送的最初一个ACK报文段可能达到B。这个ACK报文段有可能失落，B收不到这个确认报文，就会超时重传连贯开释报文段，而后A能够在2MSL工夫内收到这个重传的连贯开释报文段，接着A重传一次确认，重新启动2MSL计时器，最初A和B都进入到CLOSED状态，若A在TIME-WAIT状态不期待一段时间，而是发送完ACK报文段后立刻开释连贯，则无奈收到B重传的连贯开释报文段，所以不会再发送一次确认报文段，B就无奈失常进入到CLOSED状态。避免已生效的连贯申请报文段呈现在本连贯中。A在发送完最初一个ACK报文段后，再通过2MSL（2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活工夫，2MSL就是一个发送和一个回复所需的最大工夫。），就能够使这个连贯所产生的所有报文段都从网络中隐没，使下一个新的连贯中不会呈现旧的连贯申请报文段。为什么是四次挥手？因为当服务器端收到客户端的SYN连贯申请报文后，能够间接发送SYN+ACK报文。然而在敞开连贯时，当服务器端收到客户端收回的连贯开释报文时，很可能并不会立刻敞开SOCKET，所以服务器端先回复一个ACK报文，通知客户端我收到你的连贯开释报文了。只有等到服务器端所有的报文都发送完了，这时服务器端能力发送连贯开释报文，之后两边才会真正的断开连接。故须要四次挥手。 httpshttps 协定之所以是平安的是因为 https 协定会对传输的数据进行加密，而加密过程是应用了非对称加密实现。但其实，https 在内容传输的加密上应用的是对称加密，非对称加密只作用在证书验证阶段。https = https+加密+身份认证+完整性爱护https的整体过程分为证书验证和数据传输阶段，具体的交互过程如下： 证书验证阶段浏览器发动 HTTPS 申请服务端返回 HTTPS 证书客户端验证证书是否非法，如果不非法则提醒告警数据传输阶段当证书验证非法后，在本地生成随机数通过公钥加密随机数，并把加密后的随机数传输到服务端服务端通过私钥对随机数进行解密服务端通过客户端传入的随机数结构对称加密算法，对返回后果内容进行加密后传输非对称加密与对称加密对称加密对称加密：对称加密又叫做私钥加密，即信息的发送方和接管方应用同一个密钥去加密和解密数据。对称加密的特点是算法公开、加密和解密速度快，适宜于对大数据量进行加密，常见的对称加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。其加密过程如下：明文 + 加密算法 + 私钥 => 密文解密过程如下：密文 + 解密算法 + 私钥 => 明文对称加密的毛病是密钥平安治理艰难:因为对称加密的算法是公开的，所以一旦私钥被泄露，那么密文就很容易被破解非对称加密非对称加密：非对称加密也叫做公钥加密。非对称加密与对称加密相比，其安全性更好。对称加密的通信单方应用雷同的密钥，如果一方的密钥遭泄露，那么整个通信就会被破解。而非对称加密应用一对密钥，即公钥和私钥，且二者成对呈现。私钥被本人保留，不能对外泄露。公钥指的是公共的密钥，任何人都能够取得该密钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密。被公钥加密过的密文只能被私钥解密，过程如下： 明文 + 加密算法 + 公钥 => 密文， 密文 + 解密算法 + 私钥 => 明文被私钥加密过的密文只能被公钥解密，过程如下：明文 + 加密算法 + 私钥 => 密文， 密文 + 解密算法 + 公钥 => 明文非对称加密的毛病是加密和解密破费工夫长、速度慢，只适宜对大量数据进行加密。在非对称加密中应用的次要算法有：RSA中间人攻打http协定被认为不平安是因为传输过程容易被监听者勾线监听、伪造服务器，而https协定次要解决的便是网络传输的安全性问题。首先咱们假如不存在认证机构，任何人都能够制作证书，这带来的平安危险便是经典的“中间人攻打”问题。“中间人攻打”的具体过程如下： 本地申请被劫持（如DNS劫持等），所有申请均发送到中间人的服务器中间人服务器返回中间人本人的证书客户端创立随机数，通过中间人证书的公钥对随机数加密后传送给中间人，而后凭随机数结构对称加密对传输内容进行加密传输中间人因为领有客户端的随机数，能够通过对称加密算法进行内容解密中间人以客户端的申请内容再向正规网站发动申请因为中间人与服务器的通信过程是非法的，正规网站通过建设的平安通道返回加密后的数据中间人凭借与正规网站建设的对称加密算法对内容进行解密中间人通过与客户端建设的对称加密算法对正规内容返回的数据进行加密传输客户端通过与中间人建设的对称加密算法对返回后果数据进行解密因为短少对证书的验证，所以客户端尽管发动的是 HTTPS 申请，但客户端齐全不晓得本人的网络已被拦挡，传输内容被中间人全副窃取 https协定变更http1.0和http1.1的区别?长连贯：http1.0默认应用短连贯，每次申请都须要建设新的TCP连贯，连贯不能复用。http1.1反对长连贯，复用TCP连贯，容许客户端通过同一连贯发送多个申请。不过，这个优化策略也存在问题，当一个队头的申请不能收到响应的资源时，它将会阻塞前面的申请。这就是“队头阻塞”问题。断点续传：http1.0 不反对断点续传。http1.1 新增了 range 字段，用来指定数据字节地位，反对断点续传。谬误状态响应码：在http1.1中新增了24个谬误状态响应码，如409（Conflict）示意申请的资源与资源的以后状态发生冲突、410（Gone）示意服务器上的某个资源被永久性的删除。Host头解决：在http1.0中认为每台服务器都绑定一个惟一的IP地址，因而，申请音讯中的URL并没有传递主机名。到了http1.1时代，虚拟主机技术倒退迅速，在一台物理服务器上能够存在多个虚拟主机，并且它们共享一个IP地址，故http1.1减少了HOST信息。http1.1和http2.0的区别？新的二进制格局: http1.1 基于文本格式传输数据；http2.0采纳二进制格局传输数据，解析更高效。多路复用：在一个连贯里，容许同时发送多个申请或响应，并且这些申请或响应可能并行的传输而不被阻塞，防止 http1.1 呈现的”队头梗塞”问题。头部压缩，http1.1的header带有大量信息，而且每次都要反复发送；http2.0 把header从数据中拆散，并封装成头帧和数据帧，应用特定算法压缩头帧，无效缩小头信息大小。并且http2.0在客户端和服务器端记录了之前发送的键值对，对于雷同的数据，不会反复发送。比方申请a发送了所有的头信息字段，申请b则只须要发送差别数据，这样能够缩小冗余数据，升高开销。服务端推送：http2.0容许服务器向客户端推送资源，无需客户端发送申请到服务器获取。https与http的区别？http是超文本传输协定，信息是明文传输；https则是具备安全性的ssl加密传输协定。http和https用的端口不一样，http端口是80，https是443。https协定须要到CA机构申请证书，个别须要肯定的费用。http运行在TCP协定之上；https运行在SSL协定之上，SSL运行在TCP协定之上。

1990年前的历史上世纪九十年代前，互联网还没有被创造进去，那时候的网络根本以发邮件（Email1965年创造）等模式简略实用 1990年后的世界Tim Berners-Lee（下文中称为李爵士） 在 1989 年至 1992 年间，创造了 WWW（World Wide Web）次要蕴含三个概念URI，俗称网址HTTP，两个电脑之间传输内容的协定HTML，超级文本，次要用来做页面跳转URL 的作用是能让你拜访一个页面，HTTP 的作用是让你能下载这个页面，HTML 的作用是让你能看懂这个页面完满搭配干活不累李爵士除了创造了这些概念，还：创造了第一个服务器创造了第一个浏览器写出了第一个网页因而他取得了计算机科学畛域最富盛名的的奖项——图灵奖万维网之父Tim Berners-Lee获图灵奖：奖金100万美元（点击查看获奖信息）URI（Uniform Resource Identifier）是一个用于标识某一互联网资源名称的字符串URI 分为 URL 和 URN，咱们个别应用 URL 作为网址 URN（对立资源编码）ISBN: 9787115275790 就是一个 URN，通过 URN 你能够确定一个「惟一的」资源，ISBN: 9787115275790 对应的资源的是《JavaScript 高级程序设计（第三版）》这本书。你去是介绍任何一个图书馆、书店，他们都晓得是这本书。URL（对立资源定位符）通过 URL 你能够确定一个【惟一的】地址（网址） 一级域名com二级域名baidu三级域名www www.baidu.com DNS输出域名输入IPServer + Client + HTTP浏览器负责发动申请服务器在 80 端口接管申请服务器负责返回内容（响应）浏览器负责下载响应内容HTTP 的作用就是领导浏览器（Clinet）和服务器（Server）如何进行沟通申请示例1.url -s -v -H "Frank: xxx" -- "https://www.baidu.com"申请的内容为 GET / HTTP/1.1 Host: www.baidu.com User-Agent: curl/7.54.0 Accept: / Frank: xxx curl -X POST -s -v -H "Frank: xxx" -- "https://www.baidu.com"申请的内容为 ...

前言作为软件开发者，咱们晓得所有看似失常的零碎，不知埋藏着多少坑。明天跟大家分享一个实战过程中遇到的HTTP Client使用不当导致的坑。 笔者通过问题的表象一路追踪上来，最终找到导致问题的本源：HTTP Client。论断很简略，先卖个关子，但剖析的过程值得你借鉴。 问题景象场景：简直每个零碎都有异步调用三方服务的性能，所负责的零碎基于阻塞队列实现了一个音讯队列，来调用三方服务。为了确保幂等性，队列是程序生产。这就导致一个问题，一旦其中一个音讯被阻塞，前面的音讯就无奈生产。当队列满时，也无奈向队列中增加音讯。 看似：极其偶发的场景下，音讯队列被阻塞十多分钟。这是什么鬼？ 上面就开始了问题的逐渐排查。 问题排查首先想到的是，是不是音讯队列实现的底层机制有问题。比方音讯队列是通过while(true)轮训+sleep睡眠来实现生产者和消费者的继续存取数据。 既然音讯被阻塞，是否是因为sleep（睡）过头了？起初一想，即便CPU进行了分片解决，也不至于睡眠那么就不会被唤醒。同时也不太可能是线程被interrupted掉。因为，如被interrupted掉了，整个队列就挂了，不会提早后恢复正常。 在此处困惑了很久，看了音讯队列实现的源码很久，没有冲破。于是，与敌人探讨了一下，一句话揭示了我：可能不是睡眠的问题，而是生产者或消费者的问题。 于是认真扒日志，发现还真是的：生产者向队列中丢了一次数据，继续很长时间没有再丢数据；消费者在生产者向队列丢数据之后几分钟还有生产的日志。很显著，生产者是被消费者阻塞了。 初步论断：消费者生产工夫过长，导致队列满了，生产者向队列增加数据时被阻塞。 经验性猜想：消费者中有HTTP申请，HTTP申请可能长时间持有连贯未开释。 问题本源当剖析定位到是HTTP申请的起因，就很好解决了。首先剖析了日志，发现确实有一个HTTP申请，申请前打印了申请参数，但始终没看到返回后果的打印。扒日志终于看到，返回后果的日志是在15分钟之后打印进去的，日志内容为对方服务异样。 再看看代码，发现HTTP申请是基于HTTP Client实现的，而当初写这段代码的人并没有设置超时工夫。为了放弃业务脱敏，找了一段相似的代码： public static String doPostWithJSON(String url, String json) throws Exception { CloseableHttpClient client = HttpClients.createDefault(); HttpPost httpPost = new HttpPost(url); httpPost.setHeader("Content-Type","application/json;charset=UTF-8"); StringEntity se = new StringEntity(json, Charset.forName("UTF-8")); se.setContentType("application/json"); httpPost.setEntity(se); CloseableHttpResponse response = client.execute(httpPost); HttpEntity entity = response.getEntity(); String result = EntityUtils.toString(entity, "UTF-8"); return result;}像上述代码一样，设置了申请参数，但未指定HttpPost的超时工夫。看似失常的代码，暗藏着一个微小的坑，导致的后果就是HTTP申请始终期待。 笔者所遇到的状况还好，对方设置的超时工夫为15分钟，还给返回了后果。如果对方未设置超时工夫，可能就始终期待了，当业务量比拟大时，会导致劫难的产生！ HTTP Client的超时设置找问题往往是最难，当找到问题时，解决起来就容易多了。HTTP Client的不同版本有不同的设置超时工夫的形式，这也算是HTTP Client的又一大弊病吧，API版本变动太大。 4.3版本的配置： httpClient.getParams().setParameter(CoreConnectionPNames.CONNECTION_TIMEOUT,10000);httpClient.getParams().setParameter(CoreConnectionPNames.SO_TIMEOUT,10000);4.3当前版本的配置： RequestConfig requestConfig = RequestConfig.custom().setSocketTimeout(10000).setConnectTimeout(10000).build();httpGet.setConfig(requestConfig);其中，setConnectTimeout为连贯超时工夫，单位为毫秒。 ...

前言在开始这篇文章之前想先说一句：如果一套零碎临时没问题，那只是因为它的并发量不够而已。 上周在查看系统日志时，发现了一条不同凡响的日志。日志中有一半内容是失常的报文数据，而另一半内容是0x00这样的空数据。 尽管零碎没抛出任何异样，但这些日志必定是反常的。多年的教训通知我，这其中肯定有什么不对的中央，加上好奇心的驱使，终于揭开了一个暗藏十分深的Bug。 有时候找到Bug，解决Bug很容易，难的是如何发现Bug，并推理出哪里出问题解决。上面就带大家来分析一下这个Bug。 奇怪的日志输入一个调用内部接口的根底类，打印出相似如下的日志： abcdabcdabcdabcdabcdabcdabcd<0x00><0x00><0x00><0x00><0x00>其中后面的abcd是失常的业务数据，前面莫名其妙的多出了很多<0x00>。 那么，这个根底工具类有多根底？多处应用该办法，每天大概被调用几十万次吧，而下面的状况一天只会呈现几次。就是那么巧，恰好被看到了。 查看代码，初步推断，可能是byte数组转String时，byte数组后半部分为空或存在一些无奈转换的数据导致的。 旧代码剖析这里先把业务代码脱敏，写成一个demo展现给大家看看： public static void oldCode() throws IOException { // 通过HttpURLConnection读取的内部零碎返回的流 InputStream in = new ByteArrayInputStream("abc".getBytes()); // 明确晓得的报文长度（解析Header取得） int bodyLen = 2048; byte[] body = new byte[bodyLen]; int recvLen = 0; while (recvLen < bodyLen) { recvLen = in.read(body, recvLen, bodyLen - recvLen); if(recvLen == -1){ break; } } System.out.println(new String(body, "GBK"));}上述代码进行了业务脱敏解决，仅为还原根本的应用过程。 业务场景的大略应用流程是：第一，通过HTTP调用近程接口；第二，读取接口返回的字节流，Inputstream；第三，解析字节流，存入字节数组；第四，将字节数组转换为String。 而日志中看到的异样内容，便是打印String时呈现的。后面咱们曾经推断，呈现<0x00>的可能性是字节数组有一部分为空导致或数据谬误导致的。 上述代码有一个显著的谬误，你是否可能看进去？依据代码原始的写法，揣测之所以呈现这个谬误是因为使用者对InputStream的read办法并不相熟导致的。 这里读者先自行浏览看看上述代码的Bug在哪里，上面咱们来介绍一下InputStream的read办法。 InputStream的read办法InputStream这个抽象类是示意字节输出流的所有类的超类，它提供了3个常常被应用的read()办法： read()，无参办法。该办法从输出流中读取数据的下一个字节。返回0到255范畴内的int字节值。如果因为曾经达到流开端而没有可用的字节，则返回值 -1 。该办法会处于阻塞状态，期待数据的达到，直到返回值为-1或抛出异样。read(byte b[], int off, int len)：将输出流中最多len个数据字节读入byte数组。尝试读取len个字节，但读取的字节也可能小于该值。以整数模式返回理论读取的字节数。read (byte[] b)：从输出流中读取肯定数量的字节，并将其存储在缓冲区数组b中。以整数模式返回理论读取的字节数。剖析一下下面的三个办法。 ...

HTTP常见状态码 2XX：服务器胜利解决信息200：OK，申请胜利201：OK，新的资源建设206：Partial Content，胜利返回主体要求的数据区间（通过Content-Range指定）3XX：申请的资源产生了变动，须要用新的URL从新申请资源301，302都会在响应头中应用Location字段指明后序须要跳转的URL301：Moved Permanently，所申请的资源被永久性重定向为新的固定URL302：Found，所申请的资源被临时性重定向为另外的URL4XX：客户端谬误状态400：Bad Request，客户端的申请有谬误，但不具体401：Unauthorized，未被受权，用户须要认证404：Not Found，找不到申请的资源405：Method Not Allowed，所申请的资源不反对对应的申请办法5XX：服务端谬误状态500：500 Internal Server Error，服务器外部呈现过错501：Not Implemented，服务器不意识或不反对对应的申请办法502：Bad Gateway，谬误网关，服务器作为代理失常，然而执行后端理论业务的服务器法及时实现解决，导致连贯超时

其实应该说，麻利我的项目比传统我的项目更灵便。 因为麻利我的项目能够一边施行一边验证纠正问题，对于需要范畴不明确，需要变更较多的我的项目而言，能够很大水平上响应及拥抱变动。对于互联网产品而言，市场风向转变很快，须要一种及时疾速的交付模式，而麻利开发则能更好地实用于此。 麻利最大的特色是迭代式开发。 绝对于非麻利开发，它是一种以用户需要为外围，继续迭代，循序渐进的开发方式。麻利绝非某一种特定的开发方法，它只是一种应答疾速变动的需要的一种软件开发能力。所以麻利开发并不在意需要是否变更，即使是在我的项目开发的前期，麻利开发仍然乐于承受需要的变更。这一点对于获得客户的满意度来说，无疑是十分具备竞争力的。 为什么大家会抉择麻利开发？不外乎是一下起因： 第一，开发周期更短。绝对于其余几种开发模式（瀑布式开发，迭代式开发，螺旋开发），麻利开发的开发周期无疑更短。它能更快的满足客户的需要，当客户需要有变更时，它也能更快的做出相应的扭转，这也是麻利快发体现在快的中央之一。 第二，更好地适应疾速变动的需要。任何时候，需要都绝不会是变化无穷的。无论后期思考得如许周到，为了适应疾速变动得市场，为了让软件系统更加欠缺，需要永远都是在不停变动的。毫不夸大地说，咱们正在开发的性能，或者在它还没上线的时候，用户曾经不须要了。麻利开发可能驾驭需要的变动，它主张承受变更，对变更能够更快的做出响应。 第三，采纳迭代形式，频繁交付可应用的软件。在麻利开发中，可能一个星期就要更新一个版本，交付一个可应用的软件。而后依据市场需求的变动，疾速的交付另一个迭代产品。在这样频繁交付过程中，更好的满足用户的需要，适应需要的变动。 当然，开发人员更喜爱传统的项目管理模式，通过后期大量且具体的需要调研，通过产品经理筛选并整顿能够实现的需要文档，拦挡施行期间的新增的需要，再交给开发人员心无旁骛地开发，就很难受。 然而时代潮流变动得太快，而传统的项目管理模式周期过长，等到一个我的项目施行完，可能过后的封口曾经过来了。而麻利开发不同，能够随时接收客户提出的新需要，到最初交付的产品也根本是与时俱进。尽管麻利我的项目令开发很好受，然而挡不住客户喜爱客户称心，这也成为本人奖金的重要起源。 哪个麻利项目管理软件比拟好？ 麻利项目管理软件我举荐织信低代码治理平台，织信平台的我的项目管理系统，通过将代码字段模块化可视化，无需代码企业员工就能够本人搭建一套零碎，而且员工上手也很快，同时也反对20W+在线数据的解决，也是一个不错的抉择。而且价格也很便宜，当初注册有免费版，专业版一年也才3600，无论什么企业都能够接受。 尽管价格便宜，但在性能方面，织信低代码平台也不会逊色：对我的项目进行阶段的布局，再将每个阶段的需要调配给开发人员，能够随时查看每个需要的开发进度，状态，并且咱们还蕴含了缺点治理，测试用例，测试计划，直到整个我的项目需要交付，都能够在本利用中实现完满闭环治理。 **织信项目管理软件性能一览：1、项目管理-打算**我的项目打算是我的项目产生和运行的根底，是施行期间进行治理的前提和根据。而我的项目打算须要确定的方向如下：确定我的项目交付日期、编制我的项目实现目标、列出行业环境因素、合成我的项目成多个可交付工作、确定我的项目资源。 织信我的项目管理系统将我的项目体系合成奴才项目组；建设我的项目文档，我的项目常识共享；我的项目估算费用逐级分解；别离我的项目的人员、设施、资料打算，将工作逐级逐级拆分和排期；辨别并责权我的项目成员，实现整个我的项目的流程协同；通过API接口，实现多零碎数据联动，一屏展现所有数据。 而织信能够作为一款项目管理软件辅助项目经理进行决策，「我的项目立项列表」中可直观设定我的项目停顿状态，包含我的项目类型、估算、竣工工夫、相干负责人……；每个「我的项目立项列表」中实时更新里程碑状况、工作状况、工作报告、品质巡检、验收状况、我的项目结项、工时投入、物资洽购、报销借款等信息，疾速把握我的项目详情，正当调配人力资源和工夫管控。 工作打算在工作打算模块，织信将我的项目工作逐级分解，匹配负责人，分配资源，制订执行日期，工作关联我的项目信息，资源分配，执行报告，企业能够依据工作工夫通过甘特图模式查看。 估算打算在该模块，企业能够依据我的项目编织估算计划，同我的项目也能够设置多估算计划，而这些估算关联我的项目理论费用产出，如果估算超出就会触发正告，并发送揭示告诉；也能够建设变更估算-审批估算等流程，实现估算的灵便治理。 资源打算依据我的项目重要性，将资源依照人员、设施、资料等分类管理；将资源打算关联我的项目工作、物料与设施星系信息，设施与物料可通过二维码治理，在我的项目完结后以此计算资源老本。 **2、项目管理-立项招标治理** 在招标治理方面，企业能够发动招标立项审批，调配招标工作，记录保留招标文档，增加过程文档，剖析招标后果，记录过程交换评论，中标后跳转立项，实现招标的全周期治理。 对我的项目的打算拆解的越细代表对我的项目的把控能力越高，途中遇到危险的概率也就越低。 我的项目建档企业能够将我的项目分为主我的项目与子项目分级管理，将我的项目信息关联合同、人员、工作打算，我的项目工作责任集体和物品；接到我的项目后，依据现有我的项目进度和人员状况，对新我的项目进行工夫排期。 而在合同方面，企业也能够将合同分类别治理，上传合同附件及评论，并关联收款打算，进行自定义立项审批流程，无效晋升合同保留的安全性。 3、项目管理：执行和监控因为我的项目是形象的指标，具体的前进过程是未知的，而且在过程中有大量须要相互依赖的关系，因而须要跟踪和协调各个工作，确保过程的稳固进行。执行项目管理的重点如下：治理流动的绩效、作出变更我的项目的要害决策、监督我的项目停顿、为指标采取决策。 建设我的项目综合监控看板，可进行工作执行跟踪，质量检查列表、后果、问题归档，关联跟踪人员、设施、资料、费用报销，设置我的项目安全值设定与预警等，当呈现报警及时发送告诉。 这部分占项目经理主观决策较多，而项目管理软件能辅助的只有工作状况的反馈，例如，当工作的理论实现耗时与打算相比呈现偏差时，管理者就要为我的项目采取措施给予调整。 织信为此搭建的「我的项目看板」就能够解决这个问题，成员每实现一项子工作或规定期限已到时，该当填入本人为此工作所耗费的工时，当实现工作耗时更短时，能够调整预期工作用时；当期限内无奈实现工作时，能够调整工夫或变更适合的人选来执行。 此外，企业能够通过我的项目看板模块进行单个我的项目纬度的经营剖析，设置工期倒计时，统计我的项目估算耗费与单局数据，统计我的项目执行数据，企业经营状况高深莫测。 工作执行报告创立工作执行报告，企业就能够实时查问工作进度，挪动汇报执行报告，上报工时，汇报时提交后果附件、照片、签名，工作关联资源列表，同步人工、资料、设施产值，无效催促工作进度。 品质治理在品质模块，企业能够自定义质量检查和安全检查，并将查看关联工作，查看项列表，质检人员可挪动端确认查看我的项目状况，上报查看后果，随时随地上报我的项目品质，并将问题生成整改工作进入工作打算，以晋升日后我的项目的交付品质。 老本治理老本治理方面，企业能够将我的项目工作与报销、物料、设施老本单据关联，治理员工报销/对公报销、设施租赁、耗费资料等老本，还能够自定义费创立用治理流程，匹配企业的工作流环节，设置超预算自动控制，如有超出就会发送告诉至相干人员。 变更与预警在我的项目交付过程中，总会有变更，在织信我的项目管理系统，企业也能够自定义更改我的项目内容申请流程，并将合同、估算、打算记录等内容同步至我的项目相干人员；同时，设置收款、付款、我的项目逾期、平安问题预警值，超出平安预警后，将会在PC与挪动端推送揭示。 4、工程项目管理：项目分析当我的项目的指标曾经实现时，该我的项目达到了它的起点。结项后的回顾与总结目标在于为日后的项目管理积攒教训。 当我的项目实现后，整顿后的我的项目信息有一个可视化的出现，以便供成员和管理者有一个深刻的理解，并进行复盘。结项复盘次要分为两个方面： 一方面是对整个我的项目的打算、组织、执行状况、进度、品质、老本进行评估；另一方面是评估各个工作中执行成员的实现状况，指出执行过程中的有余并进行反思。 织信工程项目管理软件具备数据运算能力，能更直观高效地精细化核算我的项目状况，为便当整个复盘环节，织信能够依据企业需要，针对我的项目中老本、成交量、品质、数量等不同维度的指标自行设定生成可视化报表，且10种图表视图可供选择，维度灵便且开发疾速。 项目分析通过仪表盘设置自定义多种数据报表，剖析所有整体项，查看我的项目执行列表、我的项目排行与趋势、支出与收入构造等，可理解公司我的项目的低劣状况。 执行剖析依据以往教训，通过自定义多种数据报表，剖析人员工时与我的项目部门工时，最终得出工作执行是否执行以及执行工夫时长等。 **5、工程项目管理-企业驾驶舱数据分析**在企业驾驶舱，企业能够做到能够采集汇总各部门数据，并依据工夫维度同步数据，生成报表与图示，以此进行多维度数据的剖析。 织信报表企业还能够通过多种报表形式，拖拽式操作，组合属于本人企业的驾驶舱，数据及时推送、实时更新，随时随地查看企业倒退状况；依据数据分析后果，正当布局企业最佳倒退门路，升高危险；企业信息透明化流转，缩小不必要的沟通，实现高效治理。 以上就是织信工程项目软件的全生命周期治理功能模块，然而，织信除了以上列举的性能外，还能做的性能有很多，反对自定义拓展模块，反对企业自主配置（如：客户、人事、财务、绩效、销售、经营、客服等等）。是工程项目管理的得力助手。

前言Hello 大家好，我是 Sam Zhang。 HTTP 置信是每个 Web 开发者都耳熟能详的名词了。然而，老手开发者想要齐全了解 HTTP 协定却须要工夫。这期视频，我就来带大家入门 HTTP 协定。 话不多说，咱们间接进入正题！ TCP / IP 模型在真正解说 HTTP 协定之前，咱们先来看一下更为底层的 TCP / IP 模型。 TCP / IP 模型的四个档次 正如大家所看到的，TCP / IP 模型分为四层，由下到上顺次是： 链路层（Link Layer）网络层（Internet Layer）传输层（Transport Layer）应用层（Application Layer）链路层链路层处于 TCP / IP 模型的最底层。它负责管理数据如何与物理媒介进行交互，例如 Wi-Fi 定义了数据如何进行无线传输。 网络层链路层只能在局域网中工作，而网络层定义了 IP 协定，次要负责寻址操作。 传输层传输层次要负责提供利用程序接口，为应用程序提供接入网络的路径。除此以外，这一层还呈现了端口，也就是客户端与服务器连贯的频道。 最次要的是，这一层有牢靠传输的 TCP 协定。通过 TCP 协定传输的数据都能保障依照程序到达，内容正确且没有反复。大多数网络申请都是通过 TCP 传输的。 应用层这一层包含了次要为应用软件应用的协定，例如负责文件传输的 FTP 协定，负责电子邮件的 SMTP 协定和负责域名零碎的 DNS 等。最经常出现的 HTTP / HTTPS 协定也是在这一层下的，在浏览器中应用十分宽泛。WebSocket 协定也同属于这一层。 HTTP / HTTPS 协定根底概念 ...

大家好呀，我是小菜~ 本文次要介绍 网络 如有须要，能够参考! 如有帮忙，不忘 点赞 ❥ 微信公众号已开启，菜农曰，没关注的同学们记得关注哦！ 咱们先思考一个问题, 什么是网络? 网络 这个货色在咱们的生存中堪称是如影随形! 然而网络这个词又太过泛化, 咱们最直观的意识就是关上浏览器, 输出某个地址, 而后给咱们响应出页面. 既然有了网络, 为了通信失常, 就呈现了各种各样的 网络协议, 协定的次要作用就是 束缚, 只有单方相互恪守协定, 那么通信能力失常的走上来 ! 那么咱们平时接触最多的是什么协定呢? 有小伙伴就抢答了, Http 协定 ! 又有的小伙伴说是 Https 协定 两个答复都是正确的, 失常来说能够统称为 Http 协定, 而带上锁的就是 Https 协定, 那么这两个协定有什么不同呢? 这就是咱们这篇要讲到的内容 HTTPHTTP ( Hypertext Transfer Protocol ), 超文本传输协定 一. 历程回顾看到这个词莫名有种亲切感, 因为它贴近咱们的生存, 咱们能够回顾它的成长历程 1991 年 它诞生了, 过后名为 HTTP 0.9, 这个版本极其简略, 只有一个 Get 命令, 也就是只能获取资源 1996 年通过 5 年的工夫, 孵化了 1.0 这个版本, 也就是 HTTP 1.0, 这个版本有了很大的降级, 以至于当初大多数人认为 1.0 是它的初始版本, 而不晓得 0.9 这个版本的存在. 这个版本绝对成熟, 任何格局的内容都能够发送, 这使得互联网不仅能够传输文字，还能传输图像、视频、二进制文件, 这为互联网的大倒退奠定了根底 ! ...

OKR是一种基于后果和实现状况的比拟先进的团队治理形式，由英特尔公司创始人安迪·葛洛夫（AndyGrove）创造。基于织信OKR治理，利用通过透明化确定月/季/年指标（Objective），拆分合成要害后果（每周确认实现进度），再将要害后果调配给团队成员进行每日的工作执行，以此逐渐实现年度指标，晋升管理效率和工作效率。 在国外很多公司都曾经纯熟应用OKR治理办法，国内大厂也早早用了起来。所以通过问你有没有用OKR带团队，人事就能够晓得你以往的工作习惯工作形式，工作理念是传统的还是先进的，是否能率领团队，是否能适应大厂的工作格调等。 企业应用OKR治理办法，能够帮忙员工确定每天每周每月工作事项的先后顺序，在肯定周期内为企业和团队设定的策略和指标。在每一个周期完结的时候，OKR可能帮你评估团队指标的执行和实现状况。 OKR是什么？ Objectives 每一家公司都有在将来的一段时间内渴望达成的指标，但抉择正确的指标往往没那么简略，这须要破费很多的精力去思考和很多的勇气去欠缺，例如销售额一个亿，或者晋升商机线索缩量等一个大范畴的指标，至于怎么实现这个大指标，有很多办法，而这些办法就是上面的KR。 Key Results Key Results就是对下面设定好的Objective的过程性或后果性形容，它是有具体数值的，比方你想晋升网站注册量，不是设成“大幅晋升网页注册量”，而应更具体一些：日均注册超过100。 Execute 其实到KR还没完，还有一个Execute，是实现KR的各种办法路径，是基于具体工夫的具体事件，如，晋升网站注册量，能够做百度、头条、抖音推广、知乎文章等办法，什么时候开始做，什么时候完结，工作是否实现，如果没有实现及时调整并阐明起因，以此起到催促每个工作顺利按时进行，从而推动工作的稳步推动。 应用织信OKR的话，还有OKR看板，企业员工团队领导通过OKR看板，就能够晓得目前OKR进度状况，如有卡顿停滞，团队领导也能够立刻反馈，及时调整。 晓得OKR实践不难，难的是落地施行。很多人或多或少都理解OKR实践，施行落地到公司就很难推广，起因一是施行办法不对，再者OKR是要基于零碎能力施行，很多公司没有零碎，或者零碎没有专门的OKR治理援用，所以导致施行失败。OKR零碎举荐咱们的织信OKR治理利用，当初注册能够收费试用。 如何落地施行OKR？ OKR 首先是沟通工具：团队中的每个人都要写OKR，所有这些OKR都会放在一个文档里。任何员工都能够看到每个人在这个季度最重要的指标是什么，团队这个季度的指标是什么。OKR是致力的方向和指标：OKR代表你到底要去哪里，而不是你要去的中央具体在哪里。OKR必须可量化（工夫&数量）。比方健身时设定锤炼指标，如果只是定义成“咱们要努力提高身体素质”，必定不是一个好的OKR，因为无奈掂量，好的OKR是“比方2021年的跑步工夫比2020年的跑步工夫增加一倍”。 指标必须统一：制定者和执行者指标统一、团队和集体的指标统一。首先，制订公司的OKR；其次，每个团队定本人的OKR；第三，每个工程师或设计师写各自的OKR。这三步各自独立实现，而后对照协调这三者的OKR。OKR跟集体绩效没有关系，因为OKR零碎的后果和每个人并不间接挂钩。 指标要是有野心的，有一些挑战的，有些让你不难受的。一般来说，“最佳”的 OKR分数在0.6-0.7之间，如果某人只拿到1分，那么他 OKR订的指标显然是野心不够的。然而低分数的人也不应该受到指摘，而是应通过看他工作上的数据，帮忙他改良下一季度的 OKR 指标。 通过月度会议Review ，时时跟进OKR： 在月度会议上须要确定如何去达到目标，是一个帮忙达到目标的过程。 通过季度会议Review ，及时调整OKR：互联网的变动十分快，每季度有一个OKR 的 review，调整的准则是指标（Objectives）不变，只容许调整要害成绩（Key Results）。 OKR管理工具举荐 当代企业根本都有企业微信、钉钉等考勤和协同办公工具，局部公司还配置了CRM来治理客户和商机线索，然而这些零碎平台性能都很繁多，并不能用来记录、上传、更新和查看OKR的数据，所以下定决心要施行OKR，就要购买一个OKR治理利用来推动施行。 市面上成熟的OKR管理工具很多，例如飞书、维格表、织信等都是比拟好的OKR管理工具，特地是织信平台，因为采纳低代码开发模式，灵活性强，无需代码根底，通过拖来拽就能够实现零碎模块性能的增删，反对挪动端操作；而且能够对接企业微信、钉钉、CRM等已有平台和零碎，无缝连接新旧数据。最重要的是价格便宜，是传统OKR管理工具的一半，小企业也能够用。

0. 概览本书以用户在浏览器进行一次进行 HTTP 拜访作为线索，讲述网络的运作机制。在用户在浏览器输出网址开始，到浏览器接显示出页面为止整的个过程中，全书依照控制权转移的程序，顺次介绍了网络的两个次要的组成部分：信息 传输机制（网络协议和路由器、交换机等） + 应用软件（浏览器、Web服务器），在整个网络申请之中，是如何分工和合作的。 1. 第一章第一章中，次要介绍浏览器从接管到用户输出的 URL 开始，到开始发送 HTTP 申请音讯这一过程。 解析 URL生成 HTTP 报文确定 Web 服务器 IP 地址委托 OS 发送报文1.1 解析 URLURL 是什么URL（Uniform Resource Locator）对立资源定位符，用于形容某一资源的地位，输出 URL 也就相似于，打电话时要先输出对方的电话号码，URL 标识了这次申请的协定类型和目的地。 URL 的几种类型URL 结尾到第一个 ":" 之前的局部，标识了 URL 的协定类型，如http、ftp、file 等。对于不同的网络协议，URL 的写法也有各自的规定，本书将重点介绍的是 HTTP 网络协议。 1.2 生成 HTTP 报文通过解析 URL，咱们曾经晓得了咱们要拜访的指标。接下来的一步，就是生成发送给拜访指标的申请报文，申请报文的格局是有严格规定的。那么，咱们再来看看 HTTP 报文的格局。 1.2.1 HTTP 申请报文的格局申请行申请报文的首行，由 Method + URI + HTTP-Version 独特组成，它们之间应用空格隔开。对于 method，method 用于标识申请的动作类型，如 增加、删除、读取，它的值并不在 URL 中体现，而是由浏览器依据理论状况来断定。音讯头音讯头与申请行之间没有空行，它由若干键值对组成，每个键值对占一行。音讯头的最初，有一个空行，标识音讯头完结，并以此来隔开音讯头与音讯体。字段名 : 字段值··· ··· : ··· ···音讯体音讯体用于承载此次申请想要提交的信息，往往在 PUT、POST 申请才会用到1.2.2 HTTP 响应报文的格局响应行响应报文的第一行，由 HTTP-Version + 状态码 + 状态短语 独特组成。响应报文的格局中，除了这第一行响应行的格局区别与申请行，其余部分的格局，都与申请报文统一。音讯头格局同申请报文音讯体格局同申请报文 ...

背景信息以后用户在 Apache APISIX 中开发自定义插件时，能够为插件定义一些 API（下称 public API），比方在以后的 jwt-auth 插件中，它实现并提供了一个/apisix/plugin/jwt/sign 接口用于签发 JWT，因为此接口不是通过 Admin API 增加的，因而无奈像治理 Route 一样治理此类接口。 在理论利用场景中，提供的接口是面向外部调用的，而非凋谢在公网供任何人调用。为了应答这种场景，Apache APISIX 设计了 plugin-interceptors （插件拦截器），通过此性能能够让 public API 利用局部插件并实现申请过滤，然而以后仅反对 ip-restriction 插件。 由上能够看出，Apache APISIX 对于 public API 的申请过滤能力是比拟弱的，所以不能应用 Apache APISIX 中其余插件实现简单的认证和受权能力。 因而，Apache APISIX 设计了 public-api 插件，它替换了性能无限且应用简单的插件拦截器。通过这个插件，能够解决 public API 应用过程中的痛点，您能够为 public API 设置自定义的 uri，能够配置任何类型的插件。下图展现了应用 public-api 前后的变动。 不反对在 Docs 外粘贴 block 初识 public-api本节以 jwt-auth 插件的 /apisix/plugin/jwt/sign 接口为例，为您介绍两种 public-api 插件的应用办法和一种场景示例。 在应用 public-api 插件之前，如果在插件开发中应用 _M.api() 注册了 public API 后，APISIX 会默认将它裸露进去，您能够间接在 HTTP 端口调用这个 API。当初，您须要手动创立一个路由，配置 public-api 插件，才能够将 API 转发至 public-api 插件中。 ...

http-proxy 是一个有用的代理工具库，实用于 HTTP 申请的代理和重定向。 创立代理服务器的办法： var httpProxy = require('http-proxy');var proxy = httpProxy.createProxyServer(options);options 为代理服务器创立参数。 一些例子：创立代理服务器，监听在 8000 端口上，收到申请后，会转发给 端口 9000 的服务器上。 var http = require('http'), httpProxy = require('http-proxy');//// Create your proxy server and set the target in the options.//httpProxy.createProxyServer({target:'http://localhost:9000'}).listen(8000); // See (†)端口 9000 的服务器，只是简略地发送一个申请代理胜利的提示信息。 //// Create your target server//http.createServer(function (req, res) { res.writeHead(200, { 'Content-Type': 'text/plain' }); res.write('request successfully proxied!' + '\n' + JSON.stringify(req.headers, true, 2)); res.end();}).listen(9000);看个具体的例子。 我在一个 SAP UI5 利用的 manifest.json 文件里，定义了一个 dataSources，名叫 invoiceRemote，uri 为： ...

随着互联网技术的迭代更新，5G期间产生更好的观赏体验，智能手机和直播工具的不断进步为其疾速倒退提供了硬件环境，直播市场呈现暴发增长。据统计，2020年我国网络视频直播客户规模将达到5.5亿，客户增速超过9.2%。作为直播的主体之一，主播和MCN公司也出现爆发式的增长。 MCN与主播之间矛盾多多因为行业比拟新鲜，产业链不欠缺，很多MCN公司还是采纳Excel表格模式来治理主播排期，直播棚和直播设施租借记录凌乱，造成公司的损失；其次，应用抖音、快手、B站等直播平台记录和剖析主播的直播数据，剖析不全面不深刻，以致无奈评估主播的直播和带货能力。 因为以上种种原因，MCN公司与主播之间的矛盾问题也层出不穷，最出名的莫过于李子柒与杭州微念公司之间的纠纷，至今事件还没有失去解决，所以治理主播不仅仅要管人，还要治理主播直播数据、粉丝以及综合数据的剖析，以此为主播匹配适宜直播的格调或者带货货物，晋升主播的盈利能力，这才算是真正的治理。 尽管这两年直播很火，然而市场上病没有这样现成的软件，去定制的话对于直播公司来说老本又太高，而低代码模式既能满足自主定制开发，又能满足低成本开发的需要。上面就以咱们的产品织信低代码平台，来讲讲如何实现一个人治理1000个主播的问题。 织信主播治理实现建档立卡，一键查看织信的主播管理系统，全流程跟踪主播招募-培训-上岗-绩效考核，以人为本，无效治理“人”；其次，智能剖析主播与商品的匹配度，由货找人转换为人找货；最初，主播工资主动结算，主观评估主播带货能力，以此晋升企业无效的盈利能力。 当主播入驻公司后，公司能够在织信零碎建设主播卡片，录入主播信息并进行审核治理；同时，该卡片关联主播的合约、排期、培训、直播销售记录等数据，只需点击一下，主播理论的直播能力就能见高下；设定绩效计算形式，依据直播成果智能计算当月绩效工资，无效解决当今主播和直播公司之间对于薪酬的矛盾，也为日后的长期单干提供良好的根底。 依据主播的直播状况，直播公司能够通过织信平台的仪表盘性能，建设饼状、柱状等模式的自定义报表，记录主播销售走势，剖析主播粉丝构造，统计主播销售商品品类占比，并依据主播销售属性剖析，匹配适应的直播商品，以此晋升每位主播的直播能力和带货能力。 多维度剖析直播间，主观评估直播数据除了主播治理性能之外，织信的直播管理系统还能够从直播打算、直播间及直播剖析三大方面对公司的直播进行治理，助力直播间-设施-打算-排期闭环实时合作，帮忙直播高效运行；同时，可对直播进行全貌剖析，从商品、人气、流量、投放等维度联合剖析直播状况。 在直播打算利用，直播公司能够在织信自主制订页面款式制与查看直播打算，将打算关联直播人员、设施、直播间、物料、商品、直播脚本等信息；自定义直播申请流程，从直播前、中、后进行把控。 直播间治理方面，织信反对直播间信息录入，治理直播间相干设施资源，直播间关联直播打算、物料、设施，可自定义直播间治理打算、清洁、设施查看。 针对单场直播进行全貌剖析，直播要害数字指标统计；直播中销售、在线人数、趋势剖析；反对设置销售转换漏斗，统计直播商品销售占比，并将每场直播复盘剖析在线存档等。 此外，在直播带货方面织信平台还能够链接抖音、快手、淘宝直播、小红书等直播平台，对接供应商仓库，联动库存，实时记录商品的销售数据并统计到后盾，不必预先人工记录，可为直播公司节俭不少的人力物力。 值得注意的是，织信的电商管理系统人事管理、财务管理等等利用，能够在治理的主播和直播业务的同时，能够治理公司整体的运作流程，晋升公司整体合作能力以及办公效率。最重要的是实现一个平台通用，大大降低直播公司实现企业数字化转型的老本，堪称是直播公司的必备良品。

TCP/IP四层模型，如下图所示。TCP是属于网络分层中的运输层(有的书也翻译为传输层)，因为OSI分为7层，感觉太麻烦了，所以分为四层就好了，简略。 TCP连贯 建设起一个TCP连贯须要通过“三次握手”：第一次连贯：客户端被动向服务端发送syn（syn=x）数据包，本人进入syn_send状态，期待服务端的响应。第二次握手：服务端承受到了来自客户端的syn数据包，服务端向客户端发送ack（ack=x+1）和本人的syn（syn=y）数据包，本人进入到syn_recv状态。第三次握手：客户端承受到来自服务端的ack和syn数据包，客户端再向服务端发送ack（ack=y+1）数据包，此包发送结束，客户端和服务器进入ESTABLISHED状态，实现三次握手。 TCP三次握手如图： 握手过程中传送的包里不蕴含数据，三次握手结束后，客户端与服务器才正式开始传送数据。现实状态下，TCP连贯一旦建设，在通信单方中的任何一方被动敞开连贯之前，TCP连贯都将被始终放弃上来。断开连接时服务器和客户端均能够被动发动断开TCP连贯的申请，断开过程须要通过“四次握手”（过程就不细写了，放到下一篇文章再做具体阐明） HTTP连贯 HTTP连贯最显著的特点是客户端发送的每次申请都须要服务器回送响应，在申请完结后，会被动开释连贯。从建设连贯到敞开连贯的过程称为“一次连贯”。 在HTTP 1.0中，客户端的每次申请都要求建设一次独自的连贯，在解决完本次申请后，就主动开释连贯。在HTTP 1.1中则能够在一次连贯中解决多个申请，并且多个申请能够重叠进行，不须要期待一个申请完结后再发送下一个申请。因为HTTP在每次申请完结后都会被动开释连贯，因而HTTP连贯是一种“短连贯”，要放弃客户端程序的在线状态，须要一直地向服务器发动连贯申请。通常的做法是即时不须要取得任何数据，客户端也放弃每隔一段固定的工夫向服务器发送一次“放弃连贯”的申请，服务器在收到该申请后对客户端进行回复，表明晓得客户端“在线”。若服务器长时间无奈收到客户端的申请，则认为客户端“下线”，若客户端长时间无奈收到服务器的回复，则认为网络曾经断开。

HTTP申请复用TCP连贯问：与服务端建设HTTP连贯后会断开TCP连贯吗，下一次申请须要从新建设连贯吗？ 答：在HTTP1.0的时候建设HTTP连贯后默认会断开TCP连贯，除非在申请头设置COnnection=keep-alive，然而keep-alive须要服务器反对。在之后的HTTP1.1中默认反对长连贯，除非申请头中设置Connection=close。 一个TCP连贯中HTTP连贯能够一起发送吗HTTP1.1存在一个问题，单个TCP连贯同一时刻只能解决一个申请，意思是只能等到上一个申请相应了能力发送下一个申请。HTTP1.1应用了pipelining技术来解决这个问题，能够先发送所有的申请而不必期待相应，然而相应后果必须和申请的程序统一，然而这样也会有一个问题就是前面的申请响应必须等到后面的响应完能力开始解决。这也称为队头阻塞 在测试中，申请1和申请2顺次发送，申请1在服务端提早2000ms才返回，依照这个pipelining实践，申请1返回后果之前申请2不应该失去响应，但实际上申请2的响应并未被阻塞，而后发现申请2独自建设了连贯，发现是express的关系，测试发送两个申请1，发现第二次发送复用了第一次申请的建设的TCP并且第一次响应胜利，第二次才响应，并且总共等待时间为4000ms,第二次申请期待第一次响应完才开始解决同一浏览器对同一host建设TCP连贯数量有限度吗有，HTTP1.1时代chrome个别是6个。 http1.0到1.1做的优化就是默认长连贯和一个连贯能够发送多个http申请HTTP2 中应用多路复用技术解决同时发送申请的问题 强缓存### 强缓存在命中缓存时不会从新发动申请，间接从浏览器获取缓存。 Expires 设置缓存过期工夫 http1.0的产物Cache-Control 设置缓存规定，取值可能是public，private，max-age，s-max-age，no-cache，no-store，http1.1的产物cahe-control优先级高于Expires ### 强制缓存生效后，会启用协商缓存Last-modified和if-modified-since 服务器响应返回Last-modified值为文件批改工夫，当再次申请这个资源时，申请头会设置if-modified-since 值为Last-modified的值，如果没有区别会返回304和空的响应体。ETag和If-None-Match ETag是资源的惟一标识，由服务端返回，浏览器申请同一资源时，会将这个值放在If-None-Match中ETag是基于资源内容的，Last-modified是基于资源批改工夫的，精度及优先级上ETag的形式更高。 ### 理论如何应用缓存策略对于频繁变动的资源，强缓存策略设置no-cache 不走强缓存，在通过ETag走协商缓存对于不常常变动的资源，通过强缓存策略的max-age设置 http1.1存在问题线头阻塞 尽管能够同时发送多个申请，然而还是要期待上一个响应完了，再解决下一个响应http1同时发送多个申请，针对同一域名只能同时发送固定个数的申请，其余申请被阻塞，晓得服务端有响应，其余申请能力真正被收回去，其余申请期待的工夫就是stalled工夫。 http2降级了什么多路复用 用于解决线头阻塞问题，能够边响应边发送申请，不必期待，http2发送多个申请二进制分帧 绝对与http1.1的文本传输，二进制传输解析性能高效头部压缩 同一个字段屡次申请不会反复发送 HTTPSHTTP通信存在的问题内容为明文，容易被窃听无奈证实内容的完整性，容易被篡改无奈验证通信方的身份，容易被假装什么是HTTPSHTTPS是在传输层和应用层封装了一层SSL或者TLS层 加密 ：应用对称加密算法和协商密钥进行数据加密完整性 ： 基于散列函数验证信息的完整性认证：应用非对称加密实现身份认证HTTPS如何解决加密问题对称加密加密的密钥和解密的密钥必须是同一个，没有密钥就无奈解密，同理，只有有密钥谁都能够解密，但在互联网如何平安的传输密钥就是个问题 非对称加密加密的密钥和解密的密钥不雷同。解密方公开公钥，本人保留对应的私钥，加密方依据公钥加密内容，解密方用私钥解密内容。这个过程即便两头被人拦挡内容，晓得了加密算法，没有私钥也无奈实现解密。参考求模运算。齐全应用非对称加密也无奈解决完整性和平安问题，并且非对称加密性能低。 解决形式HTTPS应用非对称加密传输对称加密的密钥，而后应用对称加密传输内。因而，对称加密的密钥无奈被拦挡，所以无奈取得对称加密的密钥，因而保障了内容加密无奈破解。 HTTPS如何解决客户端先申请服务器的公钥PK，而后发送一个随机数num1，应用公钥加密后发送给服务端，服务端用本人的私钥解密拿到num1；之后的通信服务端和客户端通信都应用num1进行对称加密，因为num1只有客户端和服务端晓得，两头被拿到了没有服务端的私钥就无奈解密拿到num1。 但问题出在客户端须要先申请服务端的公钥，这个过程如何保障平安？ 如果黑客两头拦挡了申请，并向客户端发送了本人的公钥，而后客户端用黑客的公钥加密发送数据给黑客，黑客用本人的私钥进行解密，客户端实际上和黑客在通信。 问题就出在客户端申请服务端PK的过程可能会被伪造，所以要将申请PK的过程也加密。想方法不去申请PK，而是将PK内置到操作系统中。因而引入第三方CA证书，当时内置了第三方证书的PK。服务端须要请机构给本人颁发lic，lic是CA将服务端的PK应用私钥加密后的后果。当初，客户端申请服务端时，服务端返回CA颁发给本人的lic，客户端拿到lic后，能够应用CA的pk进行解密失去服务端的PK 这时候如果黑客在服务端返回lic时候拦挡申请，即便能够通过CA的pk进行解密，如果试图批改服务端的PK然而没有CA的私钥无奈对数据进行加密，这样就保障了PK无奈被批改。 通过CA证书的形式就解决了身份认证的问题，应用非对称加密传输建设对称加密的密钥就保障了数据的加密。 然而当初是否保证数据不被篡改呢，或者是数据被篡改后客户端/服务端可能感知到，即保证数据的完整性？答案是不行，黑客即便不晓得内容，但还是能够随便批改数据包的内容，这样客户端/服务端就无奈失去正确的数据包。 这时候就须要散列函数，散列函数给传输内容生成一个数字签名

文｜曾柯（花名：毅丝 ) 蚂蚁团体高级工程师 负责蚂蚁团体的接入层建设工作次要方向为高性能平安网络协议的设计及优化 本文 10279 字 浏览 18 分钟 PART. 1 引言作为系列文章的第一篇，引言局部就先略微繁琐一点，让大家对这个系列文章有一些简略的认知。 先介绍下这个系列文章的诞生背景。QUIC、HTTP/3 等字眼想来对大家而言并不生疏。从集体的视角来看，大部分开发者其实都曾经有了一些背景常识，比方 HTTP/3 的外围是依赖 QUIC 来实现传输层及 TLS 层的能力。而谈及其中细节之时，大家却又知之甚少，相干的文章大多只是浅尝辄止的对一些 HTTP/3 中的机制和个性做了介绍，少有深刻的剖析，而对于这些机制背地诞生起因，设计思路的剖析，就更难得一见了。 从集体并不大量的 RFC 浏览及 draft 写作经验来看，和撰写论文文献一样，为了保障一份 RFC 的精简以及表述精确，当然也是为了编写过程的简略。在波及到其余相干协定时，作者往往是通过间接援用的形式来进行表述。这也就意味着间接通过浏览 RFC 来学习和理解网络协议是一个曲线绝对比拟平缓的过程，往往读者在浏览到一个要害局部的时候，就不得不跳转到其余文档，而后反复这个令人头痛的过程，而当读者再次回到原始文档时，可能都曾经忘了之前的上下文是什么。 而 HTTP/3，波及到 QUIC、TLS、HTTP/2、QPACK 等规范文档，而这些规范文档各自又有大量的关联文档，所以学习起来并不是一个容易的事。 当然，系列文章的立题为“深刻 HTTP/3”，而不是“深刻 QUIC”，其背地的起因就是 HTTP/3 并不仅仅只是 QUIC 这么一个点，其中还蕴含有大量现有 HTTP 协定和 QUIC 的有机联合。在系列文章的后续，也会对这一部分做大篇幅的深入分析。 一个协定的性能优良与否，除了自身的设计之外，也离不开大量的软硬件优化，架构落地，专项设计等工程实践经验，所以本系列除了会针对 HTTP/3 自身个性进行分享之外，也会针对 HTTP/3 在蚂蚁落地的计划进行分享。 引言的最初，也是本文的正式开始。 据统计，人类在学习新的常识时，比拟习惯从已有的常识去类比和推断，以产生更粗浅的理性和理性认识。我想对大部分同学而言，“TCP 为什么要三次握手以及四次挥手？”这个问题，颇有点经典的不能再经典的滋味，所以明天这篇文章也将从 QUIC 链接的建设流程及敞开流程动手，开始咱们系列的第一篇文章。 PART. 2 链接建设2.1 重温 TCP“TCP 为什么要三次握手？” 在答复问题之前咱们须要理解 TCP 的实质，TCP 协定被设计为一种面向连贯的、牢靠的、基于字节流的全双工传输层通信协议。 “牢靠”意味着应用 TCP 协定传输数据时，如果 TCP 协定返回发送胜利，那么数据肯定曾经胜利的传输到了对端，为了保证数据的“牢靠”传输，咱们首先须要一个应答机制来确认对端曾经收到了数据，而这就是咱们相熟的 ACK 机制。 ...

文档构造以下章节解释了 Spring Data 为 Apache Geode 提供的外围性能：Bootstrapping Apache Geode with the Spring Container形容了为配置、初始化和拜访 Apache Geode 缓存、区域和相干分布式系统组件提供的配置反对。应用 Apache Geode API解释了 Apache Geode API 与 Spring 中可用的各种数据拜访性能之间的集成，例如基于模板的数据拜访、异样转换、事务管理和缓存。应用 Apache Geode 序列化形容了对 Apache Geode 的托管对象序列化和反序列化的加强。POJO 映射形容了应用 Spring Data 存储在 Apache Geode 中的 POJO 的持久性映射。Spring Data for Apache Geode Repositories形容了如何通过应用根本的 CRUD 和简略的查问操作来创立和应用 Spring Data Repositories 来拜访存储在 Apache Geode 中的数据。函数执行的正文反对形容了如何通过应用正文来执行数据所在的分布式计算来创立和应用 Apache Geode 函数。间断查问 (CQ)形容了如何应用 Apache Geode 的间断查问 (CQ) 性能来解决基于趣味的事件流，该趣味应用 Apache Geode 的 OQL（对象查询语言）定义和注册。在 Apache Geode中疏导 Spring ApplicationContext形容了如何ApplicationContext 应用Gfsh.示例应用程序形容了随发行版提供的示例，以阐明 Spring Data for Apache Geode 中可用的各种性能。 ...

简介存在即是正当，SOCKS5的呈现是为了解决SOCKS4中不反对身份认证的大问题而呈现的，毕竟大家对网络中的平安越来越器重了。没有认证的网络就如同是生存在摄像头下的人生，毫无隐衷可言，切实是太可怕了。 明天给大家深刻解说一下SOCKS5和它的利用。 为什么要应用SOCKSSOCKS是一种代理服务协定，为什么会要有代理服务协定呢？ 因为在古代网络中，很多状况下，因为网络或者防火墙的起因，咱们很难间接去拜访对方的网络，所以须要一种代理机制来充当本地网络和大型网络之间的网关。 代理服务器通过拦挡发送方和接管方之间的连贯来工作。 所有传入的数据都通过一个端口进入，并通过另一个端口转发到指标网络中。 当然流量转发是代理服务器的最根本的性能，代理服务器还能够通过暗藏客户端或者服务器端的IP地址，从而实现网络拜访的安全性。另外因为代理服务器充当了指标服务器的代理，所以能够将代理服务器作为指标服务器的缓存服务器，从而进步网络拜访效率。 另外代理服务器还能够通过对数据进行拦挡，从而进行一些非凡的操作，比方对数据进行加密，从而保障数据传输的安全性。另外代理服务器还能够对客户端的拜访进行管制，比方能够阻止客户端拜访某个IP地址或者网站。 而SOCKS就是一种代理协定的规范，通过这种协定，能够实现规范的代理服务。 在企业级网络中，为了保障企业网络的安全性，通常会有装置上防火墙，这样尽管保障了企业网络的平安，然而也阻止了客户端对外界网络的拜访。所以须要一个SOCKS 代理服务器来代替客户端和指标网站之间建设连贯和进行数据通信。 SOCKS代理能够绕过防火墙来中继用户的TCP和UDP会话。 SOCKS5因为SOCKS是运行在OSI七层协定中的第五层会话层，所以它能够解决包含HTTP、HTTPS、POP3、SMTP 和 FTP等多种申请类型，所以能够应用SOCKS协定来进行邮件发送、网页浏览、文件传输等。 绝对于SOCK4来说，SOCKS5退出了认证机制，所以能够通过身份验证建设残缺的TCP连贯，SOCKS5通常和SSH一起应用，通过应用SSH加密隧道办法来中继流量。 那么为什么咱们须要应用SOCKS5呢？ 首先咱们能够通过SOCKS5来拜访防火墙前面的服务。 一般来说，为了平安起见，服务器都放在防火墙前面，然而内部的人想要拜访该服务器的话，有两种方法。第一种就是去掉防火墙，向公众凋谢该服务，然而这样会带来平安的危险。第二种就是通过设置客户端的IP白名单，来过滤非法的拜访申请。然而客户端的IP地址通常是会发送变动的，所以这种做法也是不可行的。 如果应用SOCKS5的SSH代理，就能够通过代理服务器来拜访防火墙前面的服务，从而保障服务的安全性。 另外，通过建设SSH隧道，在其中应用SOCKS5协定将各种TCP和UDP流量路由到各自的服务，那么只须要应用SSH，而不须要应用其余VPN网络。所以应用起来比较简单。 最初，因为SOCKS5只是对数据进行转发，所以出错的可能性更小，性能会更高。 SOCKS5的应用下面咱们介绍了SOCKS5的各种长处，那么SOCKS5到底该如何应用呢？接下来向大家介绍一个应用ssh命令搭建一个简略的SOCKS5代理服务器。 先看下SSH建设SOCKS服务的命令： ssh -f -C -N -D bindaddress:port name@server-f 示意SSH作为守护过程进入后盾执行。 -N 示意不执行近程命令,只用于端口转发。 -D 示意是端口上的动静转发。这个命令反对SOCKS4和SOCKS5。 -C 示意发送前压缩数据。 bindaddress 本地服务器的绑定地址。 port 示意本地服务器的指定侦听端口。 name 示意ssh服务器登录名。 server示意ssh服务器地址。 下面命令的意思是，在本机建设端口绑定，而后将其转发到近程的代理服务器上。 比方咱们能够在本机开一个2000的端口，将其转发到近程168.121.100.23这台机子上： ssh -f -N -D 0.0.0.0:2000 root@168.121.100.23有了代理服务器之后，就能够应用了，首先介绍一个怎么在curl命令中应用SOCKS代理。 咱们想通过代理服务器，拜访www.flydean.com，该怎么做呢？ curl -x socks5h://localhost:2000 -v -k -X GET http://www.flydean.com:80要想检测SOCKS的连贯，还能够应用netcat命令如下： ncat –proxy 127.0.0.1:2000 –proxy-type socks5 www.flydean.com 80 -nv总结SOCKS5是一个十分有用的代理协定，你能够在须要的时候用上它。你懂的！ ...

翟佳，StreamNative 联结创始人 Apache Pulsar 和 Apache BookKeeper PMC 成员，前 EMC 对立存储部门技术负责人，前 Streamlio 开创工程师。2020 年获选“中国开源先锋 33 人榜单”、2021 年荣获“OSCAR 尖峰开源人物”名称，开源技术布道者。 —文 | babayage编辑 | 笑 笑 天生偏好底层准则和长期主义初识开源，崇奉价值为王 与翟佳稍有接触，就能感觉到一份发自内心的笃定、松软，友人评估他“知行合一，置信底层准则和逻辑，并且信了就做”。 谈起为何当初走上存储这条技术路线，翟佳坦言“谈不上幻想、使命这么高大上”，硬要找个理由，大概是出于他那种违心钻研底层、钻研基础理论的性情偏好：本科就读于计算机系统架构业余，到了研究生期间背后选项并不算多：通信或者存储二选一，毕业后，牵强附会退出了信息存储的代名词EMC（易安信）。彼时，挪动互联网浪潮尚未狂飙突进，能预判到存储将成为数字时代重要基础设施的前瞻者并不多，翟佳意识的只是一个通俗的大道理：“只有有IT就有存储，这是一件值得长期钻研、学习的事件。” 在EMC期间，翟佳接触到了BookKeeper，也由此迎来了事业人生的第二个关键词：开源。谈起最后对开源的感触，“跟当初必定大不相同，最后对开源的了解就是公共代码，人人能够获取、能够应用，而且曾经应用于一些比拟先进的公司场景中、通过实际测验，各方面来说都是优良靠谱的抉择”。 每一位骨灰级玩家都有一段小白的已经，翟佳对于开源的深刻理解也源自多年的积攒与迭代。但不同凡响的是，从接触开源那天开始，他就始终保持“价值为王”的理念，对于所有将场景价值后置的理念、文化和宣言都不大感冒，“软件的价值在于解决世界上存在的某个问题，开源只是一种无效发明价值的伎俩”。 守业那些坑之一二：选错模式，选错社区 回顾翟佳的守业生涯，很难绕过他的好友：StreamNative CEO郭斯杰，二人在中科院计算机所是研究生同学，同样深耕于存储技术畛域，独特参加BookKeeper开源社区……妥妥的官配CP既视感。 2016年，翟佳自EMC辞职，开启了小半年的宅家模式。此时的郭斯杰曾经走上守业之路，围绕“Heron+Pulsar+BookKeeper”的端到端计划创建了 Streamlio，听闻好友在家赋闲便力邀其加盟，翟佳略一理解后感觉“底层逻辑很靠谱，价值也很不言而喻，那就试试看”。 然而，在Streamlio创立后的一年多工夫里，他们一直尝试各种商业化伎俩却收效甚微，创始人团队逐步造成了一个共识：根底软件的商业化推广须要耗费大量资源，是巨头的游戏；并且，不足场景价值实证的根底软件，技术再先进也难以失去市场认可。 于是，开源社区成为了Streamlio绝地求生的华山一路，但在开源社区的抉择上他们却犯了又一个不大不小的失误：首先抉择了开源社区最发达的美国社区，对此翟佳反思道：“做根底软件守业的企业，其实更适宜倒退速度快、变动大、数据土壤丰盛的环境——也就是国内社区。” 稍做进展，翟佳一字一顿地说了这样一句话：“对于走开源社区路线的创业项目而言，肯定要充分考虑各方面的因素，谨慎抉择社区，因为除了极少数开创性技术我的项目，对大部分我的项目而言，社区同时扮演着生产力、需要池、推广渠道和护城河的角色——没有社区，就没有生命。” 2018年10月，翟佳与郭斯杰在京沪两地举办了两场以Pulsar 为主题的 Meetup，试水社区经营建设、推广，反应之热烈远远超乎预期。 同年，二人来到了Streamlio，创立StreamNative，打造基于国内开源社区的根底软件守业模式。科创人：越来越多的创业项目抉择开源模式，您是否分享下企业抉择社区的规范？翟佳：这个话题略大，我惟一可能明确倡议的是，做根底软件我的项目的企业其实无妨试一试国内社区，因为国内企业的商业模式还是以业务驱动为主，增长快、变动大、场景丰盛，只有你的产品足够优良、足够高效，可能解决企业的问题，他们会很违心应用。另外，其实社区营销和做To C营销没有本质区别，微信的营销对象是社交需求者，开源软件的营销对象是程序员，实质都是价值与人的连贯。 “见着亮”的两个标记：落地大厂场景，Meetup爆满 在见证过技术原理杰出的BookKeeper因为过于形象而难以商业化，亲历过Streamlio期间在水面下憋气前行、不晓得何时得以喘息，体验过自认为精妙的端到端解决方案在美国开源社区遭逢礼遇……一系列艰难和挫折之后，翟佳却还是笃定地置信云原生存储这一技术方向，他认为：“环境、机会、决策、模式都可能错，唯独这个方向肯定是正确的”。而他的保持也最终见到了回报，以充沛试错、迭代的教训为燃料，StreamNative终于顺利启航。在创立8个月之后，StreamNative举办了一场Meetup，翟佳至今还记得那天的情景：从早上9:30继续到下午6:00，参与者有来自腾讯等大厂的国内搭档，有自雅虎日本特意飞来的海内搭档，“快到完结的时候我才发现，咱们曾经可能撑起整整一天的Meetup，那天我是发自内心的感觉这个事业见亮了”。 更间接的信念来自灯塔客户的必定，腾讯计费平台与短视频利用BIGO别离成为了StreamNative在线上业务场景和线下数据分析业务场景的灯塔案例： 腾讯计费平台不单对系统扩容有要求，同时也对数据服务质量要求严苛，腾讯计费平台利用 Apache Pulsar 解决日均 100亿+ 交易申请，日均生产 10T+ 数据，承载了腾讯团体每日数亿支出大盘，托管账户总量达 300 多亿；BIGO 的案例是基于大家在流场景中常常遇到的集群运维这一痛点，BIGO 借助 Apache Pulsar 与大数据生态系统的良好交融构建了实时举荐和剖析零碎，助力业务疾速倒退，升高了原来 Kafka 集群运维老本与难度，特地是扩容缩容的人力老本。 翟佳对晚期客户表白了诚挚的感激之情，在他看来“单干的实质是达成共识，根底软件要真正胜利，必须要达成大范畴、大规模的共识，否则何谈‘根底’？正因如此，根底软件的商业推广老本奇高、难度奇大。通过开源社区，疾速落地高信任度、高难度的场景价值，这是最好的信赖状，也是开源模式的劣势所在”。 守业的那些坑之三四；事儿推人，误判需要优先级 科创人：守业这一路走来，有过哪些颠覆过往认知的经验？翟佳：很多，随口就能说出好几个（笑）。 第一个就是被事件推着走，很多守业企业都经验过人少事儿多的阶段，一忙起来就只顾着“干活”，常常遗记为了什么干，也顾不上人才培养。 但坑踩多了就晓得这是不行的，解决办法有两个：一是建设布局，明确口头指标，所有的事件都要围绕指标构建口头、筹备资源，即便不足资源也做出布局，比方缺人才，那咱们须要什么样的人才能做成这件事？想分明就去找人；二是充沛受权，人不够就找，找来了就要置信战友。 布局做进去了，新的大坑也来了，守业阶段最常见的问题：资源无限，客户需要和战略规划哪个优先级更高？起初咱们认为满足付费客户的需要是正确的，客户是上帝、拿人钱财就该给人干活，但最终咱们发现这样是不对的，“客户提需要——咱们满足”这个模式存在一个基本问题：客户提的需要，未必是问题的最优解，最佳解决方案更有可能就在咱们的战略规划中，因为咱们才是这个畛域的技术专家，更理解它现存的问题和将来后劲。所以咱们减少了与客户沟通优先级的过程，帮忙客户理解“依照咱们的布局进行，问题可能更无效地被解决”。 事实证明，客户抉择你是因为信赖你，信赖你的人也违心信赖你的判断，只有沟通分明就好。 科创人：《科创人》分享过很多科创前辈的受权教训，也请您分享下您受权的实操教训？翟佳：我的格调是动摇甚至激进的受权，充沛信赖共事，在执行前我只负责与共事们确定布局、对齐指标，之后具体事件一律不论，激励共事们大胆做、释怀走，呈现问题了我再来帮你复盘、思考如何解决，没有问题就始终做上来。 ...

There are two different categories of HTTP caching. One is so-called Strong/Force Cache, whilst the other is called as Negotiation Cache. Here're the brief intro of those: Force Cache takes precedence over Negotiation Cache;Once Force Cache is hit, there is no need to interact with server-side;For Negotiation Cache, interacting with server-side is a must to determine whether the resource caching in the client-side is available.Please Notice, Negotiation Cache is just like we are not sure something that is available or not, and after getting a big YES from authority, we can take it into use with no worry. ...

HTTPHTTP为超文本传输协定，用于Web浏览器和服务器之间传递信息。该协定以明文形式发送内容，不提供数据加密，因而不适宜传输敏感信息。 HTTPSHTTPS相当于HTTP的升级版，能够对发送的内容进行加密而后再发送。其中加密的形式有SSl、TLS这两种。 HTTP和HTTPS区别：HTTP明文传输，HTTPS加密传输HTTPS协定用到CA申请证书，证书颁发机构：Symantec、Comodo、GoDaddy 和 GlobalSign 等。HTTP响应比HTTPS快，因为HTTP应用 TCP 三次握手建设连贯，客户端和服务器须要替换 3 个包，而 HTTPS除了TCP的三个包，还要加上ssl握手须要的9个包，所以一共是12个包。HTTPS其实就是建构在 SSL、TLS 之上的 HTTP 协定，所以更消耗服务器资源。

面试官：明天要不来聊聊HTTP吧？ 候选者：嗯，HTTP「协定」是客户端和服务器「交互」的一种通迅的格局 候选者：所谓的「协定」实际上就是单方约定好的「格局」，让单方都能看得懂的货色而已 候选者：所谓的交互实际上就是「申请」和「响应」 面试官：那你晓得HTTP各个版本之间的区别吗？ 候选者：HTTP1.0默认是短连贯，每次与服务器交互，都须要新开一个连贯 候选者：HTTP1.1版本最次要的是「默认长久连贯」。只有客户端服务端没有断开TCP连贯，就始终放弃连贯，能够发送屡次HTTP申请。 候选者：其次就是「断点续传」（Chunked transfer-coding）。利用HTTP音讯头应用分块传输编码，将实体主体分块进行传输 候选者：HTTP/2不再以文本的形式传输，采纳「二进制分帧层」，对头部进行了「压缩」，反对「流控」，最次要就是HTTP/2是反对「多路复用」的（通过繁多的TCP连贯「并行」发动多个的申请和响应音讯） 面试官：嗯，略微打断下。我晓得HTTP1.1版本有个管线化(pipelining)实践，但默认是敞开的。管线化这个跟HTTP/2的「多路复用」是很相似的，它们有什么区别呀？ 候选者：HTTP1.1提出的「管线化」只能「串行」（一个响应必须齐全返回后，下一个申请才会开始传输） 候选者：HTTP/2多路复用则是利用「分帧」数据流，把HTTP协定合成为「互不依赖」的帧（为每个帧「标序」发送，接管回来的时候按序重组），进而能够「乱序」发送防止「肯定水平上」的队首阻塞问题 候选者：然而，无论是HTTP1.1还是HTTP/2，response响应的「解决程序」总是须要跟request申请程序保持一致的。如果某个申请的response响应慢了，还是同样会有阻塞的问题。 候选者：这受限于HTTP底层的传输协定是TCP，没方法齐全解决「线头阻塞」的问题 面试官：哦，好的。 候选者：HTTP/3 跟后面版本最大的区别就是：HTTP1.x和HTTP/2底层都是TCP，而HTTP/3底层是UDP。应用HTTP/3可能缩小RTT「往返时延」（TCP三次握手，TLS握手） 面试官：你理解HTTPS的过程吗？ 候选者：嗯啊，HTTPS在我的了解下，就是「平安」的HTTP协定（客户端与服务端的传输链路中进行加密） 候选者：HTTPS首先要解决的是：认证的问题 候选者：客户端是须要确切地晓得服务端是不是「实在」，所以在HTTPS中会有一个角色：CA（公信机构） 候选者：服务端在应用HTTPS前，须要去认证的CA机构申请一份「数字证书」。数字证书里蕴含有证书持有者、证书有效期、「服务器公钥」等信息 候选者：CA机构也有本人的一份公私钥，在公布数字证书之前，会用本人的「私钥」对这份数字证书进行加密 候选者：等到客户端申请服务器的时候，服务端返回证书给客户端。客户端用CA的公钥对证书解密（因为CA是公信机构，会内置到浏览器或操作系统中，所以客户端会有公钥）。这个时候，客户端会判断这个「证书是否可信/有无被篡改」 候选者：私钥加密，公钥解密咱们叫做「数字签名」（这种形式能够查看有无被篡改） 候选者：到这里，就解决了「认证」的问题，至多客户端能保障是在跟「实在的服务器」进行通信。 候选者：解决了「认证」的问题之后，就要解决「窃密」问题，客户端与服务器的通信内容在传输中不会泄露给第三方 候选者：客户端从CA拿到数字证书后，就能拿到服务端的公钥 候选者：客户端生成一个Key作为「对称加密」的秘钥，用服务端的「公钥加密」传给服务端 候选者：服务端用本人的「私钥解密」客户端的数据，失去对称加密的秘钥 候选者：之后客户端与服务端就能够应用「对称加密的秘钥」欢快地发送和接管音讯 面试官：理解了 关注我的微信公众号【Java3y】来聊点不一样的！ 【对线面试官+从零编写Java我的项目】 继续高强度更新中！求star 原创不易！！求三连！！

随着东南亚等新兴市场日渐拥挤，土地面积3020万平方公里、总人口13亿的非洲被视为“最初的十亿级互联网市场”。传音开发者本次为宽广对出海非洲等新兴市场感兴趣的挪动终端开发者们带来非洲市场简介。咱们将从非洲人口经济、非洲挪动互联网详情、非洲市场机会与赛道3大方面，对非洲目前整体状况进行诠释。 本文来自微信公众号：传音开发者（ID：Transsion_Developer），传音开发者团队原创，转载单干请分割作者。 Part 1 非洲人口和经济 非洲经济高速倒退依据African Economic Outlook 2021数据显示，在2020年寰球经济受到重大影响的状况下，非洲仍然超过亚洲，成为寰球经济增长最快区域。 受疫情影响，非洲2020年GDP增速为-2.1%，预计将在2021年复原至3.4%。 人口数量爆炸，构造年轻化依据populationpyramid数据，非洲人口13 亿，占寰球人口的16%，预计2030 年将超过 16亿。非洲人口年增长速度2.65%，为寰球人口增速的2.5倍。非洲人口平均年龄为 19 岁，远低于世界均匀 30.9 岁。城镇化率增长迅速，预计2035年非洲城镇化率将达到49%。 Source：https://www.populationpyramid... Part 2 挪动互联网倒退 挪动网络浸透加剧据Statista数据显示，2020非洲的互联网用户多达5.56亿。依据We are social2020数据统计，非洲的网络渗透率最高的为南非为60%，其次为北非和西非，别离为53%和36%。中非的网络渗透率尽管最低仅为22%，但网络用户增长最高达40%。 智能手机逐渐遍及2019年非洲智能机渗透率已达约45%，预计在2025年达到67%（约为中国2016-2017年间的程度）。 据GSMA统计，2020至2025年间，寰球新增新网络连接数中的2亿多将来自撒哈拉以南非洲和北非中东地区，是中国互联网用户增量的3倍以上。 挪动数据老本升高据2021年寰球挪动数据定价（WMDP）报告，非洲有10个国家千兆字节（1GB）数据领取不到1美元。 传音主导智能手机推广美国市场剖析机构国际数据公司（IDC）6月颁布的数据显示，2021年前三个月，按出货量来看，传音在非洲智能手机占有率别离为44.3%，放弃非洲市场占有率第一的地位。三星和OPPO别离以22.9%和8.3%的份额位列非洲智能手机市场的第二和第三。 Part 3 非洲市场资本状况及机会 资本吸引度趋势良好依据Partech公布的2020年非洲科技企业融资报告，受疫情影响，2020年共347家非洲科技企业取得了359次股权风险投资，投资资金总额为14.3亿美元，同比降落29%；但融资次数仍保持高速增长，同比增长44%。 融资节点梯队确立从非洲国家或地区融资散布看，风险投资的金额和次数仍集中在尼日利亚、肯尼亚、埃及、南非等少数几个市场，前四名国家吸引了80%的风险投资。 行业赛道逐渐清晰最受欢迎的投资畛域：金融科技、农业科技、衰弱科技。从行业赛道散布看，有三个特色：1）金融科技赛道只管取得投资金额同比降落57%，依然是最热门的赛道，共取得25%的风险投资；2）对要害经济数字化转型投资成为2020年一个亮点，有6个垂直行业取得的融资超过1亿美元股权融资；3）B2B我的项目取得的股权融资占比达54%； 数据起源：Partech，2020 Africa Tech Venture Capital Report 重点赛道一：金融科技金融科技初创公司仍是非洲融资最多的初创公司，年增长率显著。2019年，垂直部门共取得65笔交易8.36亿美元，融资同比增长120%，交易量同比增长55%。 M-PESA以后非洲金融科技公司最为突出的是肯尼亚的M-PESA。M-PESA在2019年领有2360万沉闷客户，年增长12.4%。通过M-Shwari、Fuliza和KCB M-PESA等服务机构，储蓄和贷款的年增长率超过了100%。通过M-PESA的国内汇款同比增长44.6%，领取同比增长11.0%，其中C2B同比增长30.6% 。2020年4月，Visa发表与M-PESA单干，将该平台与Visa的寰球网络连接起来。重点赛道二：电子商务因为领取解决环境的改善、挪动技术的衰亡和挪动领取技术的采纳，非洲的电子商务行业在过来十年中获得了令人难以置信的增长。2019年，在30笔交易中，有1.34亿美元的融资来自电子商务，这表明融资同比增长2%，交易数量同比增长36%。 JumiaJumia Group 旗下领有目前非洲最大的电商平台 Jumia E-commerce，该平台目前领有 670 万沉闷用户，在非洲 12 个国家及地区经营，埃及和尼日利亚为最大市场，GMV 40% 来源于尼日利亚市场。商业模式上采取淘宝的平台模式，90% 为第三方卖家，沉闷卖家数量 11 万，自建物流领有超过 500 辆摩托和卡车，可运送至尼日利亚最大的 8 个城市，领取方面，目前 55% 的订单为在线领取，1500 奈拉（约 25 元人民币）以下的订单不承受货到付款。2019 年 4 月于美国上市，是非洲第一家上市的科技公司。重点赛道三：领取转账2019年，非洲大陆新增挪动领取账户5000万个，相比上一年呈现12%的增长，整个大陆挪动领取用户达到4.69亿，其中1.81亿为沉闷账户，通过挪动领取实现的交易总额达到4560亿美元。 ...

一、Cookie 是什么？HTTP Cookie（也叫 Web Cookie 或浏览器 Cookie）是服务器发送到用户浏览器并保留在本地的一小块数据，它会在浏览器下次向同一服务器再发动申请时被携带并发送到服务器上。应用场景： 会话状态治理（如用户登录状态、购物车、游戏分数或其它须要记录的信息）个性化设置（如用户自定义设置、主题等）浏览器行为跟踪（如跟踪剖析用户行为等）二、Cookie 生成过程1、生成 cookie服务器生成了 cookie 数据 并设置为 Set-Cookie 属性，蕴含在 HTTP 协定的 Header 中 ，来通知浏览器保留这些数据（除非浏览器禁用了 Cookie）。 // 服务端发给浏览器的数据HTTP/1.0 200 OKContent-type: text/htmlSet-Cookie: yummy_cookie=chocoSet-Cookie: tasty_cookie=strawberry2、存储 cookie 并回传浏览器会在接下来的申请中，把存储的 cookie 数据，设置为 Cookie 属性，蕴含 HTTP 协定的 Header 中 ，连同申请一起发送给服务器（除非设置了不发送 cookie）。 // 浏览器发给服务器的数据GET /sample_page.html HTTP/1.1Host: www.example.orgCookie: yummy_cookie=choco; tasty_cookie=strawberry三、第一方 和 第三方 CookieCookie 中的域名 与 以后站点域名雷同，称为 第一方cookie（ first-party cookie）；Cookie 中的域名 与 以后站点域名不同，称为 第三方cookie（ third-party cookie）；以后站点会应用一些其余站点资源（譬如图片、广告等），在申请第三方服务器获取这些资源时，也会返回 Set-Cookie 属性，让浏览器保留第三方的 cookie，这些cookie 次要用于用户跟踪，流量剖析等。 四、cookie 的重要属性1、Secure 和 HttpOnly性能：限度拜访 Cookie 的形式。 ...

一、问题让网站（http://www.example.com ）反对 https 协定，能失常拜访（ https://www.example.com）这个链接。 二、解决方案https 其实就是通过 ca 证书，对服务器和域名进行实名认证。这里应用公益组织 Let's Encrypt 提供的工具 certbot 收费生成 ca 证书。 1、服务器环境：Ubuntu：服务器操作系统；nginx：用于部署运行网站的服务器；www.example.com ：通过备案且能失常解析到服务器；2、装置 certbotcertbot 是 公益组织 Let's Encrypt 提供的 ca证书 生成工具。 sudo apt-get update;sudo apt-get install software-properties-common;sudo add-apt-repository ppa:certbot/certbot;sudo apt-get update;Ubuntu14用这个命令：sudo apt-get install python-certbot-nginx;Ubuntu20用这个命令：sudo apt-get install python3-certbot-nginx3、生成 ca证书# 1、执行生成命令sudo certbot --nginx# 2、呈现如下信息Which names would you like to activate HTTPS for?- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1: www.example.com# 3、输出 1 ，回车# 4、呈现如下信息Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1: No redirect - Make no further changes to the webserver configuration.2: Redirect - Make all requests redirect to secure HTTPS access. Choose this fornew sites, or if you're confident your site works on HTTPS. You can undo thischange by editing your web server's configuration.# 5、输出 2 ，回车# 6、呈现上面语句，示意生成胜利IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/www.example.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/www.example.com/privkey.pem Your cert will expire on 2019-02-25. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le4、拜访https当初即可应用 https://www.example.com 来拜访网站了。 ...

一、简介HTTP 协定，用 Header 中的 Origin 和 Referer 来示意申请链接的起源，他们在应用上有些区别。 二、Origin 详解Origin 批示了申请来自于哪个站点，只有服务器名，不蕴含门路信息，浏览器主动增加到http申请 Header 中，无需手动设置。 1、增加 Origin 的状况同源申请：POST、OPTIONS、PUT、PATCH 和 DELETE申请都会增加Origin申请头，GET或HEAD申请不会增加Origin申请头。跨域申请：所有跨域申请(CORS)都会增加Origin申请头。2、用法说明语法 Origin: ""Origin: <scheme> "://" <host> [ ":" <port> ]// 值为""，示意资源是由 data URL 指定。参数阐明： <scheme>申请所应用协定，通常是HTTP或者HTTPS。<host>服务器的 域名 或 IP。<port>可选，端口号，HTTP申请，默认端口为 80实例 Origin: https://developer.mozilla.org三、Referer 详解Referer 批示了申请来自于哪个具体页面，蕴含服务器名和门路的具体URL，浏览器主动增加到http申请 Header 中，无需手动设置。 1、不会增加 Referer 的状况起源页面采纳 file 或 data URI 协定；起源页面采纳 HTTPS 协定，而申请页面采纳 HTTP 协定；2、应用阐明语法 Referer: <url>参数阐明 url ：示意申请起源页面的绝对路径或者相对路径，但不蕴含 URL fragments (例如 "#section") 和 userinfo (例如 "https://username:password@example.com/foo/bar/" 中的 "username:password" ) ...

一、GET 和 POST 的区别？HTTP GET 办法申请指定的资源，应该只用于 获取数据 。 HTTP POST 办法 发送数据 给服务器，数据类型由 Content-Type 指定。 二、Content-Type1、语法及阐明# 语法Content-Type:media-type# 实例Content-Type: text/html; charset=utf-8Content-Type: multipart/form-data; boundary=somethingmedia-type 类型阐明，看这里！2、表单提交实例用 HTML 的 form 表单提交 POST 申请，用 enctype 属性来设置 Content-Type <form action="/" method="post" enctype="multipart/form-data"> <input type="text" name="description" value="some text"> <input type="file" name="myFile"> <button type="submit">Submit</button></form>三、参考文档HTTP中GET与POST的区别？