应用层的知识很多，有FTP文本传送协议、域名系统DNS，电子邮件、动态主机分配系统DHCP、万维网。我们来讨论一下万维网相关的一些知识点。
定义：- 万维网是一个大规模的联机式信息存储所。
- 万维网是一个分布式的超媒体系统，是超文本系统的扩充
- 作用：统一标记互联网中的万维网文档
- 组成：<协议>://<主机>/<端口>/<路径>
- 注意有时可以省略<端口>和<路径>
目前使用较多的就是Http的URL，该http协议的端口默认为80，通常省略吗，举例：
那什么时候省略路径呢？http://www.tsinghua.edu.cn
这个URL组成是<协议>://<主机>http://news.tsinghua.edu.cn/ztxw/rhsjxjxs.htm
这个URL组成是<协议>://<主机>/<路径>
- 某WWW服务器最高级别的页面
- 某组织/部门定制的页面或目录，从这样的页面可以链接到互联网与其相关的其它站点。
- 某个人设计的描述他本人情况的WWW页面
主要特点：一个基于TCP/IP协议进行数据传输的应用层协议，互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。
- 它使用TCP连接保证了数据进行可靠的传送，HTTP协议不需要了解丢包后如何重传。不了解TCP连接的：传送门
- 它本身是无连接的，就是说在通信的双方在交换HTTP报文时，没有建立HTTP连接
- 它是无状态的，什么意思呢，比如客户端A访问服务器B的某一个资源，B并不会记录A曾经来访过。
这就会造成一个问题： A向B发起n次请求，A与B之间就会建立n个TCP连接。 显然这是很浪费资源的，那我能不能说，我先建立一次TCP连接，然后我把我当前想做的n次业务做完了，我们再释放连接。是的，HTTP/1.1便是采用持续连接的方式解决这个问题。
持续连接分两种：非流水线方式：连续发送多次请求时，需要等到上一次请求应答返回之后再执行下一个请求。流水线方式：连续发送多次请求时，无需等到上一次请求应答返回之后再执行下一个请求，多请求并行发送。这进一步提高了传送作业的效率。 - 基于请求和响应：基本的特性，由客户端发起请求，服务端响应。
- 简单快速、灵活
传送门
HTTP的Get和Post有什么区别
- 本质上看，HTTP协议是基于TCP/IP的应用层协议，而Get和Post只是http的两种方法，无论用哪种方法HTTP都是使用同一种传输协议，所以在本质上他们并没有区别，但是在他们在用法上就所有区别。
- 从功能上来看的话，Get是向服务器获取查询数据的，不会改变数据库的服务数据，而Post是可以向服务器提出修改数据的。所以，在浏览器重复提交Post请求(刷新或回退)时，需要提醒用户将会重复提交表单，而Get请求则没有这个需求。
- 从数据报文内容上来看的话，除了方法名不一样，Get的参数拼接URL当中，而Post的参数写在body(请求体)里面。但是http协议也没有明确表示，Get不能把参数写在body，Post不能在URL中添加参数，只要服务器支持，也可以这么做。
下面一点都这么说，但我不知道为什么
- Get能被缓存，Post不能被缓存。
Http协议并没有对url和body的长度有所限制。
对Url长度限制大多数是浏览器和服务器的原因。解析过长的url会消耗大量资源，为了性能和安全，服务器对Url长度进行限制，防止有人恶意构建很长的url攻击服务器。
2.Get请求比Post请求安全？略微要安全一点吧，毕竟Get的参数在URL就能直观地看到，而Post的参数在Body里面。实际上都不安全，因为Http是明文传输，只要拦截到数据包，所有数据都是透明的。
3.Get的参数写法是固定的吗？在约定中，参数写在 ? 后面用 & 隔开。
但是Http协议并没有这个要求，我们也可以自己约定参数的写法，只要服务器可以解析出来。
4.Post方法会产生两个TCP数据包？有些文章当中提到，Post会将header和body分开发送，先发送header，等待服务端返回100状态码再发送body。
HTTP协议中没有明确说明Post会产生两个TCP数据包，而且实际测试chrome发现，header和body不会分开发送。
所以，header和body分开发送是部分浏览器或框架的请求方法，不属于Post必然行为。
5.当 Get只支持ASCII 字符的。但是 Post 甚至可以不受任何限制发送二进制数据？实际上这也不是很严谨的，数据类型的区别不是面对Get和Post的，而是对于Url和body的。
Url只能支持ASCII的说法源自于RFC1738
实际上这里规定的仅仅是一个ASCII的子集 [a-zA-Z0-9$-_. !*’(),] 。它们是可以“不经编码”在Url中使用。比如尽管空格也是ASCII字符，但是不能直接用在Url里。
如果有了特殊符号和中文怎么办呢？一种叫做percent encoding的编码方法就是干这个用的。即便是URL中出现中文名或二进制数据，经过编码也能在URL中使用。
而Body就自由很多了，HTTP Body相对好些，因为有个Content-Type来比较明确的定义。比如：POST xxxxxx HTTP/1.1
...
Content-Type: application/x-www-form-urlencoded ; charset=UTF-8
12
这里Content-Type会同时定义请求body的格式（application/x-www-form-urlencoded）和字符编码（UTF-8）。
这里插一嘴Put和Post有什么区别？PUT和POST都有更改指定URI的语义.但PUT被定义为idempotent的方法，POST则不是.
idempotent的方法:如果一个方法重复执行
多次，产生的效果是一样的，那就是idempotent的。也就是说：
PUT请求：如果两个请求相同，后一个请求会把第一个请求覆盖掉。（所以PUT用来改资源）
Post请求：后一个请求不会把第一个请求覆盖掉。（所以Post用来增资源）
参考：
HTTPS://blog.csdn.net/eson_15/article/details/88083280
https://blog.csdn.net/qq_41939384/article/det…
https://zhanglin.blog.csdn.net/article/d…
https://www.cnblogs.com/wind-zhou/p/12920506.html
https://www.zhihu.com/question/28586791
HTTPS使用HTTP协议进行通信是有缺点的：- 使用明文传输，内容可能被窃听
- 无法验证通信双方身份，对方可能是伪装的
- 无法保证报文的完整性，传输过程要经过很多个节点，信息也是透明的，报文可能会被篡改。
- 前面说HTTP是服务器与客户进行通信的超文本传输协议，那么HTTPS就是服务器与客户进行安全通信的超文本传输协议。
- 通俗讲，HTTPS是披着SSL/TLS外壳的HTTP
TLS是传输层加密协议，前身是SSL协议。
- SSL是一种安全协议。它在TCP之上建立一个安全通道，对利用TCP传输的应用层数据(HTTP数据报)提供安全保障。它应该是传输层协议，实际上它常用于HTTP，常被驻留于应用层，但不仅仅可以用于HTTP，而是可以应用于任何应用层的协议。
- 有种东西叫公钥和密钥(成对出现)：知道公钥可以鉴别某信息是否被密钥加密(签名)； 公钥加密的信息可以被密钥解密；
- CA是证书的签发机构，它有一对公钥和密钥，密钥进行证书的签名，公钥用于鉴别某证书是否被签名。
- 服务器有一个数字证书，该证书被CA的密钥进行签名过。
- 谷歌火狐等浏览器(客户)知道CA的公钥。
- 根据2345可得：只要服务器返回的它的证书，客户就能鉴别它的身份是否可信。
- 服务器也有一对公钥和密钥。
知道这些就可以看懂下面这个SSL建立安全会话过程的图了
- HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
- HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
- SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
- SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
- HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
看到这里，这两者之间的区别也跃然纸上了
- 从会话(连接)方式来看，HTTP本身无连接，使用TCP连接，无状态；HTTPS需要建立SSL/TSL安全会话通道，再进行通信；HTTP端口是80; HTTPS端口是443;
- 从安全角度看，HTTPS相对HTTP可以实现： 身份验证，通信内容加密，保证数据完整性；HTTPS比HTTP更安全。
- 从通信效率上来看，HTTP比HTTPS更高，因为HTTPS除了需要进行TCP三报文握手之外，还需要进行SSL握手。
- 从资源消耗上来看：HTTPS是建立SSL/TSL之上的HTTP协议，更消耗服务器资源；HTTPS需要花钱申请CA证书。
服务器仅接收到部分请求，但是一旦服务器并没有拒绝该请求，客户端应该继续发送其余的请求。
101 Switching Protocols：服务器转换协议：服务器将遵从客户的请求转换到另外一种协议。
102: 由WebDAV（RFC 2518）：扩展的状态码，代表处理将被继续执行
状态码2xx:成功200 OK：请求成功（其后是对GET和POST请求的应答文档。）
201 Created：请求被创建完成，同时新的资源被创建。
202 Accepted：供处理的请求已被接受，但是处理未完成。
203 Non-authoritative Information：文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝。
204 No Content：没有新文档。浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的。
205 Reset Content：没有新文档。但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容。
206 Partial Content：客户发送了一个带有Range头的GET请求，服务器完成了它。
状态码3xx:重定向300 Multiple Choices：多重选择。链接列表。用户可以选择某链接到达目的地。最多允许五个地址。
301 Moved Permanently：所请求的页面已经转移至新的url
302 Found：所请求的页面已经临时转移至新的url。
303 See Other：所请求的页面可在别的url下被找到。
304 Not Modified：未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
305 Use Proxy：客户请求的文档应该通过Location头所指明的代理服务器提取。
306 Unused：此代码被用于前一版本。目前已不再使用，但是代码依然被保留。
307 Temporary Redirect：被请求的页面已经临时移至新的url。
状态码4xx:客户端错误400 Bad Request：服务器未能理解请求。
401 Unauthorized：被请求的页面需要用户名和密码。
401.1：登录失败。
401.2：服务器配置导致登录失败。
401.3：由于 ACL 对资源的限制而未获得授权。
401.4：筛选器授权失败。
401.5：ISAPI/CGI 应用程序授权失败。
401.7：访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。
402 Payment Required：此代码尚无法使用。
403 Forbidden：对被请求页面的访问被禁止。
404 Not Found:服务器无法找到被请求的页面。
405 Method Not Allowed:请求中指定的方法不被允许。
406 Not Acceptable:服务器生成的响应无法被客户端所接受。
407 Proxy Authentication Required:用户必须首先使用代理服务器进行验证，这样请求才会被处理。
408 Request Timeout:请求超出了服务器的等待时间。
409 Conflict:由于冲突，请求无法被完成。
410 Gone:被请求的页面不可用。
411 Length Required:“Content-Length” 未被定义。如果无此内容，服务器不会接受请求。
412 Precondition Failed:请求中的前提条件被服务器评估为失败。
413 Request Entity Too Large:由于所请求的实体的太大，服务器不会接受请求。
414 Request-url Too Long:由于url太长，服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时，就会发生这种情况。
415 Unsupported Media Type:由于媒介类型不被支持，服务器不会接受请求。
416 Requested Range Not Satisfiable:服务器不能满足客户在请求中指定的Range头。
417 Expectation Failed:执行失败。
423:锁定的错误。
状态码5xx 服务端错误500 Internal Server Error：请求未完成。服务器遇到不可预知的情况。
501 Not Implemented：请求未完成。服务器不支持所请求的功能。
502 Bad Gateway：请求未完成。服务器从上游服务器收到一个无效的响应。
503 Service Unavailable：请求未完成。服务器临时过载或宕机。
504 Gateway Timeout：网关超时。
505 HTTP Version Not Supported：服务器不支持请求中指明的HTTP协议版本。
