Web基础:网络协议,HTTP
网络协议
比如我们中国人都说中文,中文就相当于一种协议.网络之间交互也需要协议.
网络协议指的是计算机网络中互相通信的对等实体之间交换信息时所必须遵守的规则的集合。
分类:
OSI七层参考模型和TCP/IP四层应用模型
1.OSI七层参考模型
OSI参考模型采用分层结构技术，把一个网络系统分成若干层，每一层都去实现不同的功能，每一层的功能都以协议形式正规描述，协议定义了某层同远方一个层通信所使用的一套规则和约定。
应用层
网络服务与最终用户的一个接口。
协议有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP
表示层
数据的表示、安全、压缩。（在五层模型里面已经合并到了应用层）
格式有，JPEG、ASCll、EBCDIC、加密格式等
会话层
建立、管理、终止会话。（在五层模型里面已经合并到了应用层）
对应主机进程，指本地主机与远程主机正在进行的会话
传输层
定义传输数据的协议端口号，以及流控和差错校验。
协议有：TCP UDP，数据包一旦离开网卡即进入网络传输层
网络层
进行逻辑地址寻址，实现不同网络之间的路径选择。
协议有：ICMP IGMP IP（IPV4 IPV6）
数据链路层
建立逻辑连接、进行硬件地址寻址、差错校验 [3] 等功能。（由底层网络定义协议）
将比特组合成字节进而组合成帧，用MAC地址访问介质，错误发现但不能纠正。
物理层
建立、维护、断开物理连接。（由底层网络定义协议）
2.TCP/IP四层应用模型
TCP/IP是一组用于实现网络互连的通信协议。Internet网络体系结构以TCP/IP为核心。基于TCP/IP的参考模型将协议分成四个层次，它们分别是：网络访问层、网际互联层（主机到主机）、传输层、和应用层。
应用层
应用层对应于OSI参考模型的高层，为用户提供所需要的各种服务，例如：FTP、Telnet、DNS、SMTP等.
传输层
1、提供应用程序接口，为网络应用程序提供网络访问的途径；
2、提供可以从多个应用层序接收消息的功能（多路复用），同时也提供可以把消息分发给应用程序的功能（多路分解）。
3、对数据进行错误检测、流量控制。
网际互联层
网际层主要是解决数据由一个计算机的IP如何路由到目标计算机的过程规范，我们的计算机消息发送出去后，是经过了哪些处理才能正确的找到目标计算机，其中包含了IP、ARP、RARP、ICMP等协议。
网络接入层（即主机-网络层）
网络访问层主要是管理物理网络准备所需要的数据，包括
1、与计算机网络适配器连接。
2、根据合适的方式调整数据传输（不同的传输介质和网络格式不同）
3、把数据转化为电子流或脉冲的形式在传输介质上传输。
4、对发送的数据添加错误检查信息、对接收的数据进行数据检验。
TCP/IP协议传输示意图
IP(网络之间互连的协议)
Intemet Protocol
相当于网络中的一个节点,类似于地址,我们称之为IP地址,同一个网络中,IP地址具有唯一性
查看IP指令
windows : ipconfig
linux : ip addr
TCP
TCP是一个面向连接的协议主要包括以下几个特性
1、TCP面向连接，需要进行三次握手建立连接，四次挥手断开连接。
2、面向流的处理，可以一个个字节的方式接收数据，然后把这些数据组成数据段，发给网际层。
3、对数据发送进行流量控制（滑动窗口协议），避免发送和接收方因为缓存写满而造成的数据丢失问题。
3、对数据进行校验、分段的数据有重新排序功能，对错误和丢失的数据有重发机制。
4.具有双向传输
5.防止网络出现恶性拥塞
执行原理
① 客户端的浏览器首先要通过网络与服务器建立连接，该连接是通过TCP 来完成的，一般 TCP 连接的端口号是80。 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和许可内容
② 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容
UDP
1、UDP不面向连接。
2、只有有限的错误检验机制
3、不进行流量控制
DNS
DHCP
FTP (文件传输协议)
HTTP协议
超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII形式给出；而消息内容则具有一个类似MIME的格式。
HTTP报文格式
请求行报文格式
响应行报文格式
HTTP头字段
是以key-value的形式存在,不仅可以使用标准里的Host,Conection的头字段,还可以任意添加自定义头字段
头字段注意事项
1.字段名不区分大小写,字段名里不允许出现空格,可以使用连字符"-",但不能使用下划线"_"(有的服务器不会解析带"_"的头字段).字段名后面必须紧接着":",不能有空格,而":"后的字段值前可以有多个空格
2.字段的顺序是没有意义的,可以任意排列不影响语义
3.字段原则上不能重复,除非这个字段本身的语义允许,例如Set-Cookie
状态消息
1xx:信息
| 消息 |
描述 |
|---|---|
| 100 Continue |
服务器仅接收到部分请求，但是一旦服务器并没有拒绝该请求，客户端应该继续发送其余的请求。 |
| 101 Switching Protocols |
服务器转换协议：服务器将遵从客户的请求转换到另外一种协议。 |
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 |
对被请求页面的访问被禁止。 |
| 403.1 |
执行访问被禁止。 |
| 403.2 |
读访问被禁止。 |
| 403.3 |
写访问被禁止。 |
| 403.4 |
要求SSL。 |
| 403.5 |
要求SSL 128。 |
| 403.6 |
IP地址被拒绝。 |
| 403.7 |
要求客户端证书。 |
| 403.8 |
站点访问被拒绝。 |
| 403.9 |
用户数过多。 |
| 403.10 |
配置无效。 |
| 403.11 |
密码更改。 |
| 403.12 |
拒绝访问映射表。 |
| 403.13 |
客户端证书被吊销。 |
| 403.14 |
拒绝目录列表。 |
| 403.15 |
超出客户端访问许可。 |
| 403.16 |
客户端证书不受信任或无效。 |
| 403.17 |
客户端证书已过期或尚未生效。 |
| 403.18 |
在当前的应用程序池中不能执行所请求的URL。这个错误代码为IIS 6.0所专用。 |
| 403.19 |
不能为这个应用程序池中的客户端执行CGI。这个错误代码为IIS 6.0所专用。 |
| 403.20 |
Passport登录失败。这个错误代码为IIS 6.0所专用。 |
| 404 Not Found |
服务器无法找到被请求的页面。 |
| 404.0 |
（无）–没有找到文件或目录。 |
| 404.1 |
无法在所请求的端口上访问Web站点。 |
| 404.2 |
Web服务扩展锁定策略阻止本请求。 |
| 404.3 |
MIME映射策略阻止本请求。 |
| 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 |
请求未完成。服务器遇到不可预知的情况。 |
| 500.12 |
应用程序正忙于在Web服务器上重新启动。 |
| 500.13 |
Web服务器太忙。 |
| 500.15 |
不允许直接请求Global.asa。 |
| 500.16 |
UNC授权凭据不正确。这个错误代码为IIS 6.0所专用。 |
| 500.18 |
URL授权存储不能打开。这个错误代码为IIS 6.0所专用。 |
| 500.100 |
内部ASP错误。 |
| 501 Not Implemented |
请求未完成。服务器不支持所请求的功能。 |
| 502 Bad Gateway |
请求未完成。服务器从上游服务器收到一个无效的响应。 |
| 502.1 |
CGI应用程序超时。 |
| 502.2 |
CGI应用程序出错。 |
| 503 Service Unavailable |
请求未完成。服务器临时过载或宕机。 |
| 504 Gateway Timeout |
网关超时。 |
| 505 HTTP Version Not Supported |
服务器不支持请求中指明的HTTP版本。 |
HTTP请求头概述（HttpServletRequest）
Accept：浏览器可接受的MIME类型。
Accept-Charset：浏览器可接受的字符集。
Accept-Encoding：浏览器能够进行解码的数据编码方式，比如gzip。Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。
Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到。
Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中。
Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content-Length头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。
Content-Length：表示请求消息正文的长度。
Cookie：这是最重要的请求头信息之一
From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。
Host：初始URL中的主机和端口。
If-Modified-Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“Not Modified”应答。
Pragma：指定“no-cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝。
Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。
User-Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。
UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE浏览器所发送的非标准的请求头，表示屏幕大小、颜色深度、操作系统和CPU类型。
HTTP应答头概述（HttpServletResponse）
Web服务器的HTTP应答一般由以下几项构成：一个状态行，一个或多个应答头，一个空行，内容文档。设置HTTP应答头往往和设置状态行中的状态代码结合起来。例如，有好几个表示“文档位置已经改变”的状态代码都伴随着一个Location头，而401（Unauthorized）状态代码则必须伴随一个WWW-Authenticate头。
然而，即使在没有设置特殊含义的状态代码时，指定应答头也是很有用的。应答头可以用来完成：设置Cookie，指定修改日期，指示浏览器按照指定的间隔刷新页面，声明文档的长度以便利用持久HTTP连接，……等等许多其他任务。
设置应答头最常用的方法是HttpServletResponse的setHeader，该方法有两个参数，分别表示应答头的名字和值。和设置状态代码相似，设置应答头应该在发送任何文档内容之前进行。
HttpServletResponse还提供了许多设置
setContentType：设置Content-Type头。大多数Servlet都要用到这个方法。
setContentLength：设置Content-Length头。对于支持持久HTTP连接的浏览器来说，这个函数是很有用的。
addCookie：设置一个Cookie（Servlet API中没有setCookie方法，因为应答往往包含多个Set-Cookie头）。
另外，如上节介绍，sendRedirect方法设置状态代码302时也会设置Location头。
HTTP应答头 说明
Allow 服务器支持哪些请求方法（如GET、POST等）。
Content-Encoding 文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding头（即request.getHeader("Accept-Encoding")）检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面。
Content-Length 表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入ByteArrayOutputStram，完成后查看其大小，然后把该值放入Content-Length头，最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容。
Content-Type 表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置Content-Type，因此HttpServletResponse提供了一个专用的方法setContentType。
Date 当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。
Expires 应该在什么时候认为文档已经过期，从而不再缓存它？
Last-Modified 文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置。
Location 表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。
Refresh 表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器读取指定的页面。注意这种功能通常是通过设置HTML页面HEAD区的实现，这是因为，自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是，对于Servlet来说，直接设置Refresh头更加方便。注意Refresh的意义是“N秒之后刷新本页面或访问指定页面”，而不是“每隔N秒刷新本页面或访问指定页面”。因此，连续刷新要求每次都发送一个Refresh头，而发送204状态代码则可以阻止浏览器继续刷新，不管是使用Refresh头还是。注意Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。
Server 服务器名字。Servlet一般不设置这个值，而是由Web服务器自己设置。
Set-Cookie 设置和页面关联的Cookie。Servlet不应使用response.setHeader("Set-Cookie", ...)，而是应使用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie设置的讨论。
WWW-Authenticate 客户应该在Authorization头中提供什么类型的授权信息？在包含401（Unauthorized）状态行的应答中这个头是必需的。例如，response.setHeader("WWW-Authenticate", "BASIC realm=\"executives\"")。注意Servlet一般不进行这方面的处理，而是让Web服务器的专门机制来控制受密码保护页面的访问（例如.htaccess）。
HTTP的缺点
1.数据的明文传送和消息完整性检测的缺乏
2. HTTP是明文数据传输,攻击者可以通过网络嗅探试图从传输过程中分析出敏感的数据
3.HTTP在传输客户端请求和服务端响应时, 唯一的数据完整性检验就是在报文头部包含了本次传输数据的长度, 而对内容是否被篡改不作确认。如有攻击者可以轻易发动中间人攻击修改客户端和服务端传输的数据, 甚至在传输数据中插入恶意代码, 导致客户端被引导至恶意网站被植入木马
HTTPS协议
客户端和服务端在传输数据之前,会通过基于X.509证书对双方进行身份认证
双向的身份认证
1.客户端发起 SSL 握手消息给服务端要求连接。
2.服务端将证书发送给客户端。
3.客户端检查服务端证书，确认是否由自己信任的证书签发机构签发。 如果不是，将是否继续通讯的决定权交给用户选择 ( 注意，这里将是一个安全缺陷 )。如果检查无误或者用户选择继续，则客户端认可服务端的身份
4.服务端要求客户端发送证书，并检查是否通过验证。失败则关闭连接，认证成功则从客户端证书中获得客户端的公钥，一般为1024位或者 2048位。到此，服务器客户端双方的身份认证结束，双方确保身份都是真实可靠的。
数据传输的机密性
客户端和服务端在开始传输数据之前，会协商传输过程需要使用的加密算法。 客户端发送协商请求给服务端, 其中包含自己支持的非对称加密的密钥交换算法 ( 一般是RSA), 数据签名摘要算法 ( 一般是SHA或者MD5) , 加密传输数据的对称加密算法 ( 一般是DES),以及加密密钥的长度。 服务端接收到消息之后，选中安全性最高的算法，并将选中的算法发送给客户端，完成协商。客户端生成随机的字符串，通过协商好的非对称加密算法，使用服务端的公钥对该字符串进行加密，发送给服务端。 服务端接收到之后，使用自己的私钥解密得到该字符串。在随后的数据传输当中，使用这个字符串作为密钥进行对称加密
防止重放攻击
SSL使用序列号来保护通讯方免受报文重放攻击。这个序列号被加密后作为数据包的负载。在整个SSL握手中,都有一个唯一的随机数来标记SSL握手。 这样防止了攻击者嗅探整个登录过程，获取到加密的登录数据之后，不对数据进行解密, 而直接重传登录数据包的攻击手法。
可以看到，鉴于电子商务等安全上的需求，HTTPS对比HTTP，在安全方面已经取得了极大的增强。总结来说，HTTPS的改进点在于创造性的使用了非对称加密算法，在不安全的网路上，安全的传输了用来进行对称加密的密钥，综合利用了非对称加密的安全性和对称加密的快速性
HTTPS 原理
① 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器
② 服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端；该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个用作产生密钥的随机数
③ 客户端对服务器的证书进行验证（有关验证证书，可以参考数字签名），并抽取服务器的公用密钥；然后，再产生一个称作 pre_master_secret 的随机密码串，并使用服务器的公用密钥对其进行加密（参考非对称加 / 解密），并将加密后的信息发送给服务器
④ 客户端与服务器端根据 pre_master_secret 以及客户端与服务器的随机数值独立计算出加密和 MAC密钥（参考 DH密钥交换算法
⑤ 客户端将所有握手消息的 MAC 值发送给服务器
⑥ 服务器将所有握手消息的 MAC 值发送给客户端
优缺点
优点
-
使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器 ；
-
HTTPS 协议是由 SSL+HTTP构建的可进行加密传输、身份认证的网络协议，要比 HTTP安全，可防止数据在传输过程中被窃取、改变，确保数据的完整性 。
-
HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本 。
缺点
-
相同网络环境下，HTTPS 协议会使页面的加载时间延长近 50%，增加 10%到 20%的耗电。此外，HTTPS 协议还会影响缓存，增加数据开销和功耗 。
-
HTTPS 协议的安全是有范围的，在黑客攻击、拒绝服务攻击和服务器劫持等方面几乎起不到什么作用 。
-
最关键的是，SSL 证书的信用链体系并不安全。特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行 。
-
成本增加。部署 HTTPS 后，因为 HTTPS 协议的工作要增加额外的计算资源消耗，例如 SSL 协议加密算法和 SSL 交互次数将占用一定的计算资源和服务器成本。在大规模用户访问应用的场景下，服务器需要频繁地做加密和解密操作，几乎每一个字节都需要做加解密，这就产生了服务器成本。随着云计算技术的发展，数据中心部署的服务器使用成本在规模增加后逐步下降，相对于用户访问的安全提升，其投入成本已经下降到可接受程度