应用层的知识很多，有FTP文本传送协议、域名系统DNS，电子邮件、动态主机分配系统DHCP、万维网。我们来讨论一下万维网相关的一些知识点。

定义：万维网是一个大规模的联机式信息存储所。万维网是一个分布式的超媒体系统，是超文本系统的扩充统一资源定位符URL作用：统一标记互联网中的万维网文档组成：<协议>://<主机>/<端口>/<路径>注意有时可以省略<端口>和<路径>

目前使用较多的就是Http的URL，该http协议的端口默认为80，通常省略吗，举例：

这个URL组成是<协议>://<主机>

这个URL组成是<协议>://<主机>/<路径>

那什么时候省略路径呢？某WWW服务器最高级别的页面某组织/部门定制的页面或目录，从这样的页面可以链接到互联网与其相关的其它站点。某个人设计的描述他本人情况的WWW页面超文本传输协议HTTP

一个基于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的八种方法

传送门

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不能被缓存。常见问题：1.Get请求在对URL添加参数，对URL的长度时有限制的？

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-812

这里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使用HTTP协议进行通信是有缺点的：使用明文传输，内容可能被窃听无法验证通信双方身份，对方可能是伪装的无法保证报文的完整性，传输过程要经过很多个节点，信息也是透明的，报文可能会被篡改。HTTPS就是为了解决这些问题产生的：前面说HTTP是服务器与客户进行通信的超文本传输协议，那么HTTPS就是服务器与客户进行安全通信的超文本传输协议。通俗讲，HTTPS是披着SSL/TLS外壳的HTTP

TLS是传输层加密协议，前身是SSL协议。HTTPS如何利用SSL/TSL进行安全的通信，就要知道这些知识点：SSL是一种安全协议。它在TCP之上建立一个安全通道，对利用TCP传输的应用层数据(HTTP数据报)提供安全保障。它应该是传输层协议，实际上它常用于HTTP，常被驻留于应用层，但不仅仅可以用于HTTP，而是可以应用于任何应用层的协议。有种东西叫公钥和密钥(成对出现)：知道公钥可以鉴别某信息是否被密钥加密(签名)； 公钥加密的信息可以被密钥解密；CA是证书的签发机构，它有一对公钥和密钥，密钥进行证书的签名，公钥用于鉴别某证书是否被签名。服务器有一个数字证书，该证书被CA的密钥进行签名过。谷歌火狐等浏览器(客户)知道CA的公钥。根据2345可得：只要服务器返回的它的证书，客户就能鉴别它的身份是否可信。服务器也有一对公钥和密钥。

知道这些就可以看懂下面这个SSL建立安全会话过程的图了

HTTPS的缺点HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。HTTP和HTTPS的区别？

看到这里，这两者之间的区别也跃然纸上了

从会话(连接)方式来看，HTTP本身无连接，使用TCP连接，无状态；HTTPS需要建立SSL/TSL安全会话通道，再进行通信；HTTP端口是80; HTTPS端口是443;从安全角度看，HTTPS相对HTTP可以实现： 身份验证，通信内容加密，保证数据完整性；HTTPS比HTTP更安全。从通信效率上来看，HTTP比HTTPS更高，因为HTTPS除了需要进行TCP三报文握手之外，还需要进行SSL握手。从资源消耗上来看：HTTPS是建立SSL/TSL之上的HTTP协议，更消耗服务器资源；HTTPS需要花钱申请CA证书。HTTP状态码状态码1xx100 Continue：

服务器仅接收到部分请求，但是一旦服务器并没有拒绝该请求，客户端应该继续发送其余的请求。

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协议版本。