了解Web及网络基础
概述了Web是建立在何种技术之上，以及HTTP协议是如何诞生并发展的。
本节内容来源于《图解HTTP》
使用HTTP协议访问Web
根据Web浏览器地址栏中指定的URL，Web浏览器从Web服务器端获取文件资源(resource)等信息，从而显示出Web页面。
发送请求获取服务器资源的Web浏览，都可称为客户端。
Web使用名为HTTP的协议作为规范，完成从客户端到服务器的一系列流程。可以说，Web是建立在HTTP协议上通信的。
HTTP的诞生
WWW这一名称，是Web浏览器当年浏览超文本的客户端应用程序的名称。现在则用来表示这一系列的集合，也可简称为Web。
HTTP版本
HHTP/0.9，HTTP于1990年问世。现在的HTTP其实含有HTTP1.0之前版本的意思，因此被称为为HTTP/0.9。
HTTP/1.0，HTTP正式作为标准，命令为HTTP/1.0。虽然是初期标准，但该协议至今仍被广泛应用在服务器端。
HTTP/1.1，是目前主流的HTTP协议版本，作为Web文档传输协议的HTTP，它的版本几乎没有更新。新一代的HTTP/2.0正在定制中，但要达到较高的使用覆盖率，仍需要时间。
网络基础TCP/IP
为了理解HTTP，需要先了解TCP/IP协议族。通常使用的网络（包括互联网）是在TCP/IP协议族的基础上运作的。HTTP是它内部的一个子集。
如何探测通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要时限规定。不通的硬件、操作系统之间的通信，所有的这一切都需要一种规则。而我们把这种规则称为协议。
TCP/IP的分层管理
TCP/IP协议族里最重要的一点就是分层。TCP/IP协议族按层次分为以下4层：应用层、传输层、网络层、数据链路层。
分层的好处：如果某处变化了，只需要把变动的层换掉；如果不分层是一个协议统筹，就必须换掉所有部分整体。层次化之后，设计也变得相对简单了，处于各个层只需要考虑自己的任务，而不需弄清楚其他问题。
各层的作用如下：
应用层：决定了向用户提供应用服务时的通信活动。如FTP、DNS。
传输层：传输层对上层应用层，提供处于网络连接中两台计算机之间的数据传输。协议有TCP、UDP。
网络层：网络层用来处理在网络上流动数据包，数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（传输路线）到达对方计算机，并把数据包传送给对方。
数据链路层：处理连接网络的硬件部分。
TCP/IP通信传输流
利用TCP/IP协议族进行网络通信，通过分层的顺序与对方通信。发送端从应用层往下走，接收方从链路层往应用层上走。以HTTP举例说明。
1.在应用层，作为发送端的客户端（HTTP协议）发出一个想看某个页面的HTTP请求。
2.为了传输方便，传输层（TCP协议）把从应用层处收到的数据（HTTP请求报文）进行分割，并在各个报文打上标记序号以及端口号发给网络层。
3.在网络层（IP协议）,增加作为通信目的地的MAC地址后转发给链路层。这样，发送网络的通信请求就准备齐全了。
4.接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层。当传输到应用层，次啊能算真正接收到由客户端发送过来的HTTP请求。
发送端在层与层之间传输数据时，每经过一层必定会被打上一个该层的首部信息。反之，接收端在层与层传输数据时，每经过一层时都会把对应的首部消去。
这种把数据信息包装起来的做法称为封装。
与HTTP关系密切的协议：IP、TCP和DNS
负责传输的IP协议
IP（Internet Protocol）协议位于网络层。可能有人会把IP和IP地址搞混，IP其实是一种协议的名称。
IP协议的作用是把各种数据包传送给对方。而要确保传送给对方，需要满足各类条件，其中两个重要的条件是IP地址和MAC地址。
IP地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址。IP地址可以和MAC地址进行配对，IP地址可换，MAC地址不可换。
使用ARP协议凭借MAC地址进行通信
IP间的通信依赖MAC地址。在网络上，通信的双方在同一局域网内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方。而在中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标。这是，会采用ARP协议，ARP协议是一种地址解析协议，根据通信双方的IP地址可以反查出IP地址。
没有人能够全面掌握互联网中的运输情况
在到达通信目标前的中转过程中，那些计算机和路由器等网络设备只能获悉很粗略的传输路线。
这种机制称为路由选择（routing）。
确保可靠的TCP协议
为了能够准确无误地将数据送达目标处，TCP协议采用了三次握手策略。用TCP协议把数据包送出后，TCP不会对传送的情况置之不理，它一定会向对方确认是否成功送达。握手过程中使用了TCP标志（flag）——SYN和ACK。
三次握手
建立了三次握手之后，才会在后面传输数据。
三次握手基本理解：
三次握手其实就是建立一个TCP连接，需要客户端和服务端总共发送3个包。进行三次握手的主要作用是为了确认双方的接受能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。
三次握手具体流程：
刚开始客户端处于closed状态，服务端处于Listen状态。进行三次握手：
-
第一次握手，客户端发给服务器一个SYN报文，并指明客户端初始化序列号ISN(c)。此时客户端处于**SYN_SEND**状态。
在该报文段中，SYN=1，初始序号seq=x
疑问：是不是可以理解seq=ISN -
第二次握手，服务端收到客户端的SYN报文之后，会用自己的SYN报文应答，并且也指定自己的初始化序列号ISN(s)。同时会把客户端的ISN+1作为ack的值，表示自己的收到了客户端的SYN，此时服务器处于SYN_RECD状态。
在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y
-
第三次握手，客户端收到SYN报文后，回会发送一个ACK报文。会把服务端的ISN+1作为ack的值，表示已经收到了服务端的SYN报文，此时客户端处于ESTABILISHED状态。当服务器收到ACK报文后，也会处于ESTABILISHED状态。
确认报文段ACK=1，确认号ack=y+1,序号seq=x+1。
ACK报文段可携带数据，不携带数据则不消耗序号
发送第一个SYN的一端执行主动打开(active open)，接受这个SYN并发回下一个SYN的另一端执行被动打开(passive open)。
在socket编程中，客户端执行connect()时，将触发三次握手。
为什么需要三次握手，两次不行吗？
弄清这个问题，需要先明白三次握手的目的是什么，
第一次握手，客户端发送网络包，服务端收到了。这样服务端就得出结论：客户端发送能力、服务端接受能力正常。
第二次握手，服务端发包，客户端收到了。这样客户端得出结论：服务端的接受、发送能力正常，客户端的接受、发送能力正常。但是此时服务器不知道客户端的接受能力是否正常
第三次握手，客户端发包，服务端收到了。这样服务器就能得出结论：客户端的接受能力、发送能力正常，服务器自己的发送能力和接受能力正常。
因此，需要三次握手才能确认双方的接受与发送能力正常。
如果是用两次握手，会出现下面的情况
什么是半连接队列？
服务端第一次收到客户端的SYN后，就会处于SYN_RCVD状态，此时双方还没有完全建立连接，服务器会把此种状态下的请求连接放在一个队列里，把这种队列成为半连接队列。
还有一个全连接队列，就是已经完成三次握手，建立起的连接就会放在全连接队列中。如果队列满了有可能出现丢包的情况
补充关于SYN-ACK重传次数的问题服务器发送完SYN-ACK包，如果未收到用户的确认包，服务器进行首次重传，等待一段时间仍未收到客户包确认，进行第二次重传，如果重传次数超过最大重传次数，系统将该连接信息从半连接对垒中删除。注意，每次重传等待的时间不一定相同，一般会是指数增长。
ISN（Initial Sequence Number）是固定的吗
当一端为建立连接发送SYN时，它为连接选择一个初始序号。ISN随时间变化，因为每个连接都将具有不同的ISN。ISN可以看做一个32比特计数器。这样变化目的：防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方怼他做出错误的解释。
三次握手其中一个重要功能就是客户端和服务端交换ISN，以便让对方知道接下来接受数据的时候如何按序列号组装数据。如果ISN是固定的，攻击者很容易猜出后续的确认号，因此ISN是动态生成的。
三次握手过程中可以携带数据吗
其实第三次握手，可以携带数据。但是，**第一次、第二次握手不可以携带数据。**
如果第一次握手可以携带数据，如果有人恶意攻击服务器，那么他每次都在第一次握手的SYN报文中放入大量的数据。因此攻击者根本不会在乎服务器是否接受、发送正常，疯狂发送携带大量数据的SYN报文即可，这样会让服务器花费很多时间、内存来接受这些报文。也就是说，第一次握手不可以放数据，其中一个简单的原因会让服务器更加受到攻击。
对于第三次来说，客户端已经处于ESTABLISHED状态。对于客户端来说，已经建立起了连接，并且也知道了服务器的接受、发送能力正常了，所以能携带数据也没毛病
SYN攻击是什么？
服务器端的资源是在第二次握手时分配的，而客户端的资源是在第三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN洪泛攻击是Client在短时间伪造大量不存在的IP地址，向Server不断发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。
检测SYN攻击的方法很方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。来Linux/Unix上可以使用系统自带的netstats命令来检测SYN攻击。
netstat -n -p TCP | grep SYN_RECV
常见的SYN攻击的方法有如下几种：
- 缩短超时时间
- 增加最大的半比特连接数
- 过滤网关防护
- SYN cookies
四次挥手
建立一个可靠的连接需要三次握手，而终止一个连接要经过四次挥手（也有叫四次握手的）。这是由于TCP的半关闭造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后 还能接受来自另一端数据的能力。
TCP连接的解除需要发送四个包，因此成为四次回收，客户端或服务端均可以主动发起挥手动作。
刚开始双方都处于ESTABLISHED状态，假如是客户端先发起关闭请求。四次挥手的过程如下：
-
第一次挥手：客户端发送一个FIN报文，报文中指定序列号。此时客户端处于**FIN_WAIT1**状态。
即发出连接释放报文段，并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1(中止等待1)状态，等待服务端的确认。
FIN=1,seq=u
-
第二次挥手：服务端收到FIN之后，会发送ACK报文，且把客户端的序列号+1作为ACK报文的序列号值，表明已经收到客户端的报文了，此时服务端处于**CLOSE_WAIT**状态。
即服务端收到连接释放报文段后即发出确认报文段，服务端进入**CLOSE_WAIT（关闭等待）状态**，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2(中止等待2)状态，等待服务端发出的连接释放报文段。
ACK=1，ack=u+1，seq=v
-
第三次挥手：如果服务端也想断开连接了，和客户端第一次挥手一样，发FIN报文，且指定一个序列号。此时服务端处于**LAST_ACK**的状态。
即服务端没有要向客户端发出的数据，服务端发出连接释放报文段，服务端进入**LAST_ACK**，等待客户端的确认。
FIN=1，ACK=1，序号seq=w，确认号ack=u+1
-
第四次挥手：客户端收到FIN之后，一样发送一个ACK报文你作为应答，且把服务端的序列号值+1作为自己的ack好，此时客户端处于TIME_WAIT状态。需要过一阵子以确保服务端收到自己的ACK报文之后采购进入CLOSED状态，服务端收到ACK报文后，就处于关闭连接了，CLOSED状态。
即客户端收到服务端的连接释放报文段后，对此发出确认报文段，客户端进入TIME_WAIT(时间等待状态)。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。
收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。
在socket编程中，任何一方执行close()即可产生挥手操作。
挥手为什么需次4次？
因为当服务端接受到客户端的SYN连接请求后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文用来同步的。
但是关闭连接是，当服务端收到FIN报文是，很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文，告诉客户端：’你的FIN报文我收到了’。只有等到我服务端的所有报文都发送完毕后，我才能发送FIN报文，因此不能一起发送，故需要四次握手。
负责域名解析的DNS服务
DNS服务和HTTP协议一样位于应用层的协议。它提供域名到IP地址之间的解析服务。计算机既可以被赋予IP地址，也可以被赋予主机名和域名。
用户通常使用主机和域名来访问对方的计算机，而不是直接通过IP地址访问，因为域名更符合人类的记忆习惯。但是计算机理解域名较难，更擅长处理一长串数字。
为了解决上述问题，DNS服务应运而生。DNS协议提供通过域名查找IP地址，或逆向从IP地址反查域名的服务。
各种协议与http协议的关系
客户端：
HTTP协议：生成针对目标服务木的HTTP请求报文
TCP协议：为了方便通信，将HTTP请求报文分割成报文段，将每个报文段可靠的传输给对方
IP协议：搜索对方的地址，一边中转一边传送
服务端：
TCP协议：从对方那里接收到的报文段，重组
HTTP协议：处理服务器的请求资源
使用TCP/IP协议将请求发送回去
URI和URL
URI：统一资源标识符
URL：统一资源定位符，URL是使用Web浏览器访问Web页面是需要输入的网页地址。