【Linux网络】HTTPS【下】{CA认证/证书的签发与认证/安全性/总结}

1.引入证书【为方案五铺垫】

1.1再谈https

1. HTTPS，全称Hypertext Transfer Protocol Secure，是一种在HTTP协议上加入了安全层（SSL/TLS）的协议。它通过传输加密和身份认证保证了传输过程的安全性，被广泛用于万维网上安全敏感的通讯，例如交易支付等方面。
   HTTPS的特点主要包括：
   安全性：HTTPS通过SSL/TLS协议对数据进行加密和身份验证，确保数据在传输过程中的保密性和完整性。加密保护了敏感数据的机密性，防止被第三方截获和窃取；身份验证防止了中间人攻击，确保了通信双方的身份可信。
   可信性：HTTPS使用证书来验证服务器的身份。证书由可信任的证书颁发机构（CA）签发，包含了服务器的公钥和颁发机构的数字签名。客户端在与服务器建立连接时会验证证书的真实性和合法性，确保通信双方的身份可信。
   SEO优化：搜索引擎将HTTPS作为网站排名的一个重要指标。
   安全的Cookie传输：在HTTPS连接中，所有的Cookie都会通过加密的方式传输，防止被窃取和篡改。这对于保护用户的登录凭据和敏感信息非常重要。
   用户信任度提升：使用HTTPS协议可以提升用户对网站的信任度。
   HTTPS的工作原理主要基于SSL/TLS协议，通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护。HTTPS在HTTP与TCP之间加入了一个加密/身份验证层，该层负责数据的加密和解密以及身份认证。
   HTTPS适用于任何需要保护数据安全和隐私的场景，如网络银行和电子商务网站、社交媒体平台、在线支付平台、医疗保健网站等。在这些场景中，HTTPS可以有效防止黑客通过网络监听和窃取用户信息，保护用户的敏感信息不被第三方获取。

2. 之前我们讲过的四个方案，最后一个相对于完美的方案存在的问题是，即没办法知道收到的这个信息是谁发来的，即对方身份的合法性。举例：日常生活中，警察蜀黍会在大街上查看一些看起来鬼鬼祟祟的人，目的是判断这个人是否是合法公民，身份证这个证件是第三方政府（不是你不是警察）颁发的证件，用来标识合法性。

1.2SSL/TLS

SSL（Secure Sockets Layer，安全套接层）和TLS（Transport Layer Security，传输层安全性协议）是用于在两个通信应用程序之间提供保密性和数据完整性的协议。它们主要工作在应用层和传输层之间，通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。

SSL/TLS协议的工作原理主要依赖于两个重要协议：握手协议和记录协议。握手协议负责协商加密算法、哈希算法、加密密钥，并帮助服务器和客户端相互验证。这个过程在应用程序的数据传输之前进行，并且通常包括四个步骤的握手过程。记录协议则建立在传输协议（如TCP协议）之上，对数据进行封装、压缩、加密等基本功能的支持。

SSL和TLS的关系非常密切。实际上，TLS是SSL的后续版本，它在1999年由IETF（互联网工程任务组）从SSL 3.0协议的基础上进行了标准化，并发布了TLS 1.0。TLS与SSL 3.0相比，在安全性方面进行了改进，并删除了SSL协议中存在的安全漏洞。之后，TLS又发布了多个版本，包括TLS 1.1、TLS 1.2等，每个版本都在安全性方面进行了进一步的提升。

总的来说，SSL/TLS协议是互联网通信中保障数据安全的重要协议，通过加密和身份验证技术，确保了数据在传输过程中的保密性和完整性。

1.3CA机构

1. CA认证，即电子认证服务，是指为电子签名相关各方提供真实性、可靠性验证的活动。CA机构，即Certificate Authority（证书授权机构）或称为CA中心，是负责发放和管理数字证书的权威机构，作为身份认证的有效凭据。
   CA认证的原理是通过第三方认证机构对数字证书的发放和管理，确保数字证书的真实性和可信度。CA认证的过程主要包括证书申请、申请审核、身份验证和证书发放几个环节。数字证书是包含用户公钥、用户身份信息以及CA机构的数字签名，用来确保证书的真实性和不可篡改性。
   在CA认证中，用户首先向CA提交证书申请，包括提供个人或组织的身份信息和相关证明材料。然后，CA对用户的身份和提供的信息进行验证，这通常包括核实用户的身份证件、企业注册文件等。一旦验证通过，CA会使用自己的私钥对用户的公钥进行签名，生成数字证书。数字证书包含了用户的公钥、证书的有效期、CA的签名等信息。最后，CA将签发的数字证书发送给申请者，申请者可以将证书安装到自己的设备中，以便进行加密通信或进行身份验证。
   CA机构在网络安全中起到了重要的作用，可以有效防止信息被篡改和伪造，保护用户的隐私和数据安全。同时，用户可以通过验证数字证书的真实性，来确认通信对方的身份和可信度，从而建立起安全可靠的通信环境。
   
2. CA认证
   服务端在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。
   

证书可以理解成是一个结构化的字符串,里面包含了以下信息:

证书发布机构
证书有效期
公钥
证书所有者
签名

需要注意的是:

申请证书的时候，需要在特定平台生成，会同时生成一对儿密钥对儿，即公钥和私钥。这对密钥对儿就是用来在网络通信中进行明文加密以及数字签名的。其中公钥会随着CSR文件，一起发给CA进行权威认证，私钥服务端自己保留，用来后续进行通信(其实主要就是用来交换对称秘钥)。

CSR在线生成工具

输入信息后会给出你的私钥和CSR文件（包含公钥）。形成CSR之后，后续就是向CA进行申请认证，不过一般认证过程很繁琐，网上有各种提供证书申请的服务商，如果有需要，直接找平台帮忙解决就行

1.4理解数字签名

签名的形成是基于非对称加密算法的，注意，目前暂时和https没有关系，不要和https中的公钥私钥搞混了。

1.4继续铺垫

上篇提到 前四个方案不完美的原因是

即

1. 客户端无法验证第一次“服务端”发来的公钥确实是服务端发来的
2. 客户端无法验证公钥是正确的
3. 总结：客户但无法验明对方的身份！
4. 我们前面的所有铺垫 都是在讲 如何能够验明一个人的身份！

证书的申请

1.5方案五

服务端申请证书

当服务端申请CA证书的时候，CA机构会对该服务端进⾏审核，并专⻔为该⽹站形成数字签名，过程如下：

1. CA机构拥有⾮对称加密的私钥A和公钥A’
2. CA机构对服务端申请的证书明⽂数据进⾏hash，形成数据摘要
3. 然后对数据摘要⽤CA私钥A’加密，得到数字签名S
   服务端申请的证书明⽂和数字签名S 共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了

回顾一二三

回顾方案四

方案五过程

0. 设CA自己的公钥为A，私钥为A‘。服务端自己的公钥为S，私钥为S‘。客户端自己的对称密钥X。
1. 客户端向服务端发起请求 请求CA证书 服务端给客户端自己的CA证书 证明自己的身份
2. 客户端对证书的明文数据用MD5算法形成数据摘要m，对数字签名用A解密形成数据摘要n，比对mn是否相等，相等说明服务端身份合法。提取证书中明文数据中服务端的公钥S。对X用S加密发送给服务端。服务端接收到后用S’解密获取X，之后双方用X加密交流。

方案五与方案四的区别：

方案四的S是直接发给客户端的，导致客户端无法验明S的合法性。
方案五的S是通过证书发给客户端的，这样能验明吗？接下来我们开始破解这种方案！

寻找方案五的漏洞

0. 设定中间人M，公钥M，私钥M‘
1. M对证书的明文数据修改，客户端对明文数据计算出的摘要和签名计算出的摘要不同，该方法不行！
2. M对摘要修改，客户端对明文数据计算出的摘要和签名计算出的摘要不同，该方法不行！【实际上M只对摘要修改没实际意义】
3. M对明文和摘要都修改，使得客户端对明文数据计算出的摘要和签名计算出的摘要相同，这样可以吗？不可以！客户端对签名解密时只会用CA的公钥，M对摘要修改后，用自己的M’加密，但是客户端对签名解密时只会用CA的公钥！此时客户端发现签名无法解密，意识到证书被修改了！即所有的浏览器都内置了CA的公钥，只会用CA的公钥对签名解密，这令一程度上赋予了CA机构权力==》面子是别人给的！
4. M把整个证书替换，M要想有证书，必须用自己的真实信息【域名/申请者】去申请，风险太高！其次，如果M真申请了，M就是一个合法机构，那么它就可以直接获取浏览器的请求数据了，为什么还要大费周章？此时合法的M如果用浏览器发来的数据做一些非法行为，这就是网络警察的工作了。同时，世界上没有两个完全相同的域名，如果真有人这么做了，浏览器在访问abc.com时显示的确实bca.com，浏览器是能看出来的！实际上存在一些伪网站，用和真的网站w相似的域名去申请证书，做的网站样式也和w相同，然后接收到浏览器的请求后，自己再向w发起请求，然后把w发来的响应再返回浏览器，这也是网络警察的工作！

客⼾端对证书进⾏认证

当客⼾端获取到这个证书之后, 会对证书进⾏校验(防⽌证书是伪造的).
• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置受信任的证书发布机构).
• 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到⼀个 hash 值(称为数
据摘要), 设为 hash1. 然后计算证书明文数据的 hash 值, 设为 hash2. 对⽐ hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的

2.查看证书

2.1查看浏览器的受信任证书发布机构

2.2中间⼈有没有可能篡改该证书

• 中间⼈篡改了证书的明⽂
  • 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后
  的证书形成匹配的签名
  • 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，
  证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈

2.3为什么摘要内容在⽹络传输的时候⼀定要加密形成签名

常⻅的摘要算法有: MD5 和 SHA 系列

以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点:
• 定⻓: ⽆论多⻓的字符串, 计算出来的 MD5 值都是固定⻓度 (16字节版本或者32字节版本)
• 分散: 源字符串只要改变⼀点点, 最终得到的 MD5 值都会差别很⼤.
• 不可逆: 通过源字符串⽣成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.
正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相同

理解判定证书篡改的过程: (这个过程就好⽐判定这个⾝份证是不是伪造的⾝份证)

假设我们的证书只是⼀个简单的字符串 hello, 对这个字符串计算hash值(⽐如md5), 结果为
BC4B2A76B9719D91
如果 hello 中有任意的字符被篡改了, ⽐如变成了 hella, 那么计算的 md5 值就会变化很⼤.
BDBD6F9CF51F2FD8
然后我们可以把这个字符串 hello 和 哈希值 BC4B2A76B9719D91 从服务器返回给客⼾端, 此时客⼾端如何验证 hello 是否是被篡改过?
那么就只要计算 hello 的哈希值, 看看是不是 BC4B2A76B9719D91 即可.
但是还有个问题, 如果⿊客把 hello 篡改了, 同时也把哈希值重新计算下, 客⼾端就分辨不出来了呀.所以被传输的哈希值不能传输明⽂, 需要传输密⽂.对证书明⽂(这⾥就是“hello”)hash形成散列摘要，然后CA使⽤⾃⼰的私钥加密形成签名，将
hello和加密的签名合起来形成CA证书，颁发给服务端，当客⼾端请求的时候，就发送给客⼾端，中间⼈截获了，因为没有CA私钥，就⽆法更改或者整体掉包，就能安全的证明，证书的合法性。
最后，客⼾端通过操作系统⾥已经存的了的证书发布机构的公钥进⾏解密, 还原出原始的哈希值, 再进⾏校验

为什么签名不直接加密，⽽是要先hash形成摘要?

• 缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度

如何成为中间⼈

ARP欺骗：在局域⽹中，hacker经过收到ARP Request⼴播包，能够偷听到其它节点的 (IP, MAC)
地址。例， ⿊客收到两个主机A, B的地址，告诉B (受害者) ，⾃⼰是A，使得B在发送给A 的数据包
都被⿊客截取
• ICMP攻击：由于ICMP协议中有重定向的报⽂类型，那么我们就可以伪造⼀个ICMP信息然后发送给局域⽹中的客⼾端，并伪装⾃⼰是⼀个更好的路由通路。从⽽导致⽬标所有的上⽹流量都会发送到我们指定的接⼝上，达到和ARP欺骗同样的效果
• 假wifi && 假⽹站等

3.总结

HTTPS ⼯作过程中涉及到的密钥有三组.
第⼀组(⾮对称加密): ⽤于校验证书是否被篡改. 服务器持有私钥(私钥在形成CSR⽂件与申请证书时获得), 客⼾端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客⼾端请求时，返回携带签名的证书. 客⼾端通过这个公钥进⾏证书验证, 保证证书的合法性，进⼀步保证 证书中携带的服务端公钥权威性。
第⼆组(⾮对称加密): ⽤于协商⽣成对称加密的密钥. 客⼾端⽤收到的CA证书中的公钥(是可被信任的)给随机⽣成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.
第三组(对称加密): 客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密.

其实⼀切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥⼯作的.

第⼀组⾮对称加密的密钥是为了让客⼾端拿到第⼆组⾮对称加密的公钥
第⼆组⾮对称加密的密钥是为了让客⼾端把这个对称密钥传给服务器.

4.https一定是安全的吗

https（Hypertext Transfer Protocol Secure）本身是为了提供安全的通信而设计的，它通过在HTTP协议上增加了一层加密（通常是SSL/TLS），以确保在客户端和服务器之间传输的数据是加密的、完整的，并且数据在传输过程中没有被篡改。然而，仅仅使用https并不意味着通信绝对安全，因为安全性是一个多层次、多方面的概念。

以下是https可能不是绝对安全的一些原因：

1. 中间人攻击（Man-in-the-Middle, MITM）：尽管https使用了加密，但如果攻击者能够成功地执行中间人攻击（例如，通过伪造证书或控制网络中的某个节点），他们仍然可能能够窃取或篡改数据。
   证书问题：如果服务器使用的SSL/TLS证书不是由受信任的证书颁发机构（CA）签发的，或者证书已经过期或被吊销，那么客户端可能会收到警告，并且通信可能不是安全的。
2. 弱加密算法或密钥：如果服务器使用的加密算法过时或密钥长度不够长，那么它可能容易受到暴力破解或其他类型的攻击。
   不安全的实现：即使https本身很安全，但如果服务器或客户端的实现中存在安全漏洞，那么整个通信也可能变得不安全。
3. 应用程序级别的漏洞：https只保护在传输层上的数据。如果应用程序本身存在安全漏洞（例如，SQL注入、跨站脚本攻击等），那么即使使用了https，攻击者仍然可能能够利用这些漏洞来窃取或篡改数据。
4. 用户行为：用户的行为也可能影响安全性。例如，如果用户点击了来自不受信任来源的链接或下载了恶意软件，那么他们的设备或数据可能会受到威胁。
5. 之前讲的中间人绞尽脑汁都是为了盗取客户端的信息（X），但是如果客户端就是中间人转而攻击服务器呢？即 中间人把浏览器内置的CA公钥保存一份 模拟浏览器向服务端发起请求，然后生成对称密钥M之后用M和服务端进行交流。如果想更安全的话，就考虑服务端对自己的信息做一下二次加密—了解即可
   因此，虽然https是一个很好的起点，但确保通信的安全性需要采取更多的措施，包括使用受信任的证书颁发机构签发的有效证书、使用强加密算法和长密钥、定期更新和修补软件漏洞、以及教育和培训用户采取安全的在线行为等。

5.应用层总结

应用层属于用户层 原因是不同用户有特定的需求：协议的定制 序列反序列 加密与解密 安全级别 ；
如果加密算法被攻破了，可以升级；但是如果应用层在内核，我们就需要升级内核，这是不合适的！即各种各样的需求放在用户层，这些东西无法统一，让那些用户自己搞！

6.http/https题目

如何在响应报文头部去设置字符编码（）

Content-Type：用于告诉客户实际返回的内容的内容类型或者说编码类型，比如 Content-Type: text/html; charset=utf-8 用于表示正文是 text/html文档类型，字符集为utf-8

Content-Language：用于表示用户希望采用的语言或语言组合，比如 Content-Language: de-DE 表示该文件为说德语的人提供，但是要注意这不代表文件内容就是德语的。

Content-Language更多表示上层语言的表示， 而Content-Type用于底层数据编码的表示

因此在响应报文头部设置字符编码是在Content-Type中设置charset属性，大小写不敏感。

GET请求中是不带有HTTP body的，get方式在url后面拼接参数，只能以文本的形式传递参数

GET请求中是不带有HTTP body的，get方式在url后面拼接参数，只能以文本的形式传递参数

如果没有为Cookie指定失效时间，则设置的Cookie将在何时失效？

Cookie的Expires属性指定了cookie的生存期，默认情况下cookie是暂时存在的，他们存储的值只在浏览器会话期间存在，当用户退出浏览器后这些值也会丢失，如果想让cookie存在一段时间，就要为expires属性设置为未来的一个过期日期。现在已经被max-age属性所取代，max-age用秒来设置cookie的生存期。因此当没有设定过期时间时，则退出当前会话时cookie失效，

cookie安全机制，cookie有哪些设置可以提高安全性？

1. domain：可以访问该Cookie的域名。如果设置为“.google.com”，则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.”。
2. path：Cookie的使用路径。如果设置为“/sessionWeb/”，则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”，则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/”。
3. httponly：如果cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击，窃取cookie内容，这样就增加了cookie的安全性,但不是绝对防止了攻击
4. secure：该Cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false。
5. expires:指定了coolie的生存期，默认情况下cookie是暂时存在的，他们存储的值只在浏览器会话期间存在，当用户退出浏览器后这些值也会丢失，如果想让cookie存在一段时间，就要为expires属性设置为未来的一个过期日期。现在已经被max-age属性所取代，max-age用秒来设置cookie的生存期

代码理解

Set-Cookie:
qwerty=219ffwef9w0f; 
Domain=somecompany.co.uk; 
Path=/; 
Expires=Wed, 30 Aug 2019 00:00:00 GMT

对保存到cookie里面的敏感信息加密
设置指定的访问域名
设置HttpOnly为true
设置Secure为true
给Cookie设置有效期
给Cookies加个时间戳和IP戳，实际就是让Cookies在同个IP下多少时间内失效

cookie有什么用？

记录用户的ID
记录用户的密码
记录用户浏览过的商品记录

cookie是一种保存在客户端的小型文本文件，用于保存服务器通过Set-Cookie字段返回的数据，在下次请求服务器时通过Cookie字段将内容发送给服务器。是HTTP进行客户端通信状态维护的一种方式。
cookie的可以记录用户的ID，记录用户的密码，记录用户浏览过的商品记录。但是无法记录用户的浏览器设置，浏览器设置属于浏览器，而并不属于某次请求的信息。

session默认有效期是30分钟，Cookie没有设置expires属性，那么 cookie 的生命周期只是在当前的会话中，关闭浏览器意味着这次会话的结束，此时 cookie 随之失效

session_id是session的代号或者说唯一标识，通常是不重复的整数，但是其实是否用整数倒是无所谓，主要是唯一且要方便使用

一般情况下Session是通过Cookie传递Session_ID实现的，禁用cookie则session就没法用了，但是劳动人民智慧是无穷的，可以将SESSION_ID附着在URL中来实现，也就是session并不一定完全依赖于cookie实现

cookie是一种保存在客户端的小型文本文件，用于保存服务器通过Set-Cookie字段返回的数据，在下次请求服务器时通过Cookie字段将内容发送给服务器。是HTTP进行客户端状态维护的一种方式

但是cookie存在一定的缺陷：比如有大小限制，通常不能超过4k，很多浏览器都限制一个站点最多保存20个cookie。以及cookie不断的传递客户端的隐私信息，存在一定的安全隐患（比如认为篡改），因此有了session管理

session服务器为了保存用户状态而创建的临时会话，或者说一个特殊的对象，保存在服务器中，将会话ID通过cookie进行传输即可，就算会话ID被获取利用，但是session中的数据并不会被恶意程序获取，这一点相对cookie来说就安全了一些，但是session也存在一些缺陷，需要建立专门的session集群服务器，并且占据大量的存储空间（要保存每个客户端信息）

Session可以存放各种类别的数据，相比只能存储字符串的cookie，能给开发人员存储数据提供很大的便利

在分布式架构中，存在Session共享的问题。.Session可以在多个服务器之间共享
默认情况下，Session依赖于Cookie

HTTP协议是一种以字符串明文传输的简单的请求-响应协议（HTTP协议无状态，一次请求-响应就会结束通信），在传输层基于TCP协议实现。

HTTP协议默认使用80端口

HTTPS协议是一种对HTTP加密后的协议（这里的加密采用SSL加密），主要是多了身份验证以及加密传输等功能，HTTPS协议默认使用443端口

HTTP协议是建立在 TCP/IP 协议之上的网络层规范，分为三个部分：状态行、请求头、消息主体

错误：HTTP协议，是TCP/IP协议栈中应用层的协议

HTTP协议在目前1.1版本中支持了长连接管理，也就是支持在一定时间内保持TCP连接建立，用于发送/接收多次请求

HTTP协议是无状态的协议，在最初设计的时候HTTP协议是一种简单的请求-响应协议，即一次建立连接中，完成一次请求一次响应后，通信结束关闭连接，所以是无状态的

SMTP：简单邮件协议
FTP：文件传输协议
UDP:用户数据报协议
TELNET:Internet远程登录服务的标准协议

POST请求主要用于向服务器提交表单数据，因此POST请求不会被缓存，POST请求不会保留在浏览器历史记录当中，POST请求不能被保存为书签，POST请求对数据长度没有要求

GET请求主要用于从服务器获取实体资源，资源可被缓存，可以被记录在浏览器历史记录

PUT方法请求服务器去把请求里的实体存储在请求URI（Request-URI）标识下。
如果请求URI（Request-URI）指定的的资源已经在源服务器上存在，那么此请求里的实体应该被当作是源服务器关于此URI所指定资源实体的最新修改版本。
如果请求URI（Request-URI）指定的资源不存在，并且此URI被用户代理定义为一个新资源，那么源服务器就应该根据请求里的实体创建一个此URI所标识下的资源。
如果一个新的资源被创建了，源服务器必须能向用户代理（user agent） 发送201（已创建）响应。
如果已存在的资源被改变了，那么源服务器应该发送200（Ok）或者204（无内容）响应。

HEAD请求是没有响应体的，仅传输状态行和标题部分
DELETE方法用来删除指定的资源，它会删除URI给出的目标资源的所有当前内容
PUT方法用于将数据发送到服务器以创建或更新资源，它可以用上传的内容替换目标资源中的所有当前内容

理论上讲，POST是没有大小限制的。HTTP协议规范也没有进行大小限制，起限制作用的是服务器的处理程序的处理能力，而并非限制。

HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法

404 NOT FOUND，表示客户端请求的资源不存在
302 表示临时重定向
503 由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。
403 禁止访问，服务器理解请求客户端的请求，但是拒绝执行此请求（比如权限不足，ip被拉黑等一系列原因）

301：

301 状态码表明目标资源被永久的移动到了一个新的 URI，任何未来对这个资源的引用都应该使用新的 URI。

302 状态码表示目标资源临时移动到了另一个 URI 上。由于重定向是临时发生的，所以客户端在之后的请求中还应该使用原本的 URI。
由于历史原因，用户代理可能会在重定向后的请求中把 POST 方法改为 GET方法。如果不想这样，应该使用 307（Temporary Redirect） 状态码

303 状态码表示服务器要将浏览器重定向到另一个资源。从语义上讲，重定向到的资源并不是你所请求的资源，而是对你所请求资源的一些描述。
比如303 常用于将 POST 请求重定向到 GET 请求，比如你上传了一份个人信息，服务器发回一个 303 响应，将你导向一个“上传成功”页面。

307 的定义实际上和 302 是一致的，唯一的区别在于，307 状态码不允许浏览器将原本为 POST 的请求重定向到 GET 请求上。

308 的定义实际上和 301 是一致的，唯一的区别在于，308 状态码不允许浏览器将原本为 POST 的请求重定向到 GET 请求上。

1xx:信息状态码，接受到请求正在处理
2xx:成功状态码，请求正常处理完毕
3xx:重定向状态码，需要进行附加操作来完成请求
4xx:客户端错误状态码，服务器无法处理请求
5xx:服务器错误状态码，服务器处理请求出错

Socket用于描述IP地址和端口，是一个通信链的句柄
IP协议是网络层协议，TCP和UDP协议在网络层都是基于IP协议的。（实现数据报传输）