HTTP与计算机网络
1. TCP/IP协议分层管理
应用层
- **应用层决定了向用户提供应用服务时通信的活动。**应用层负责处理特定的应用程序细节。
- TCP/IP 协议族内预存了各类通用的应用服务。比如，==FTP（File Transfer Protocol，文件传输协议）==和
DNS（Domain Name System，域 名系统）服务就是其中两类。 HTTP 协议也处于该层。
传输层
- 传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。
- 在传输层有两个性质不同的协议 TCP（Transmission Control Protocol，传输控制协议）和 UDP（User
Data Protocol，用户数据报 协议）。 - 主要为两台主机上的应用程序提供端到端的通信。在TCP/IP协议族中，有两个互不相同的传输协议：TCP（传输控制协议）和UDP（用户数据报协议）。
- TCP为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层，确认接收到的分组，设置发送最后确认分组的超时时钟等。由于运输层提供了高可靠性的端到端的通信，因此应用层可以忽略所有这些细节。为了提供可靠的服务，TCP采用了超时重传、发送和接收端到端的确认分组等机制。
- UDP则为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。一个数据报是指从发送方传输到接收方的一个信息单元（例如，发送方指定的一定字节数的信息）。UDP协议任何必需的可靠性必须由应用层来提供。
网络层
- 网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。
- 与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所 起的作用就是在众多的选项内选择一条传输路线。
- 处理分组在网络中的活动，例如分组的选路。在TCP/IP协议族中，网络层协议包括IP协议（网际协议），ICMP协议（Internet互联网控制报文协议），以及IGMP协议（Internet组管理协议）。
- IP是一种网络层协议，提供的是一种不可靠的服务，它只是尽可能快地把分组从源结点送到目的结点，但是并不提供任何可靠性保证。同时被TCP和UDP使用。TCP和UDP的每组数据都通过端系统和每个中间路由器中的IP层在互联网中进行传输。
- ICMP是IP协议的附属协议。IP层用它来与其他主机或路由器交换错误报文和其他重要信息。
- IGMP是Internet组管理协议。它用来把一个UDP数据报多播到多个主机。
链路层
- 用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱 动、NIC（Network Interface
Card，网络适配器，即网卡），及光纤等 物理可见部分（还包括连接器等一切传输媒介）。硬件上的范畴均在 链路层的作用范围之内。 - 也称作数据链路层或网络接口层（在第一个图中为网络接口层和硬件层），通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。它们一起处理与电缆（或其他任何传输媒介）的物理接口细节。ARP（地址解析协议）和RARP（逆地址解析协议）是某些网络接口（如以太网和令牌环网）使用的特殊协议，用来转换IP层和网络接口层使用的地址。
2. 三次握手四次挥手机制及原因
简要回答：三次握手才能保证双方具有接收和发送的能力。
三次握手
TCP定义
TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
TCP头
- source port 、destination port
两者分别为「源端口号」和「目的端口号」。源端口号就是指本地端口，目的端口就是远程端口。 -
Sequence Numbe
称为「***」seq。用于 TCP 通信过程中某一传输方向上字节流的每个字节的编号，为了确保数据通信的有序性，避免网络中乱序的问题。接收端根据这个编号进行确认，保证分割的数据段在原始数据包的位置。 -
Acknowledgment Numbe
称为「确认***」ack(小写)。确认***是接收确认端所期望收到的下一***。确认序号应当是上次已成功收到数据字节序号加1，只有当标志位中的 ACK 标志为 1 时该确认***的字段才有效。主要用来解决不丢包的问题。 - TCP Flag
TCP 首部中有 6 个标志比特，它们中的多个可同时被设置为 1，主要是用于操控 TCP 的状态机的，依次为URG，ACK，PSH，RST，SYN，FIN。 -
ACK：
这个标识可以理解为发送端发送数据到接收端，发送的时候 ACK 为 0，标识接收端还未应答，一旦接收端接收数据之后，就将 ACK 置为 1，发送端接收到之后，就知道了接收端已经接收了数据。 -
SYN
表示「同步***」，是 TCP 握手的发送的第一个数据包。
用来建立 TCP 的连接。SYN 标志位和 ACK 标志位搭配使用，当连接请求的时候，SYN=1，ACK=0连接被响应的时候，SYN=1，ACK=1；这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有 SYN 的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口。 -
FIN
表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志位的 TCP 数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。
三次握手过程
（1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
（2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
（3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
常见延申问题
-
三次握手的第一次可以携带数据吗？为何？
不可以，三次握手还没有完成。 -
第三次可以携带数据吗？为何？
可以。 - 能够发出第三次握手报文的主机，肯定接收到第二次(服务器)握手报文，对吗？
因为伪造IP的主机是不会接收到第二次报文的。
所以，能够发出第三次握手报文的，应该是合法的用户 - 看到有人说，只看到过TCP状态位为 ’FIN +ACK’，但从来没有看过状态位只有 ‘FIN’，你应该怎样给他解释？
除了第一个握手报文SYN除外，其它所有报文必须将ACK = 1。 -
为什么不是一次、二次握手？
为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。如果此时客户端发送的延迟的握手信息服务器收到，然后服务器进行响应，认为客户端要和它建立连接，此时客户端并没有这个意思，但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。
服务端收到延迟的报文，以为你要和它连接，所以会给你发送确认同意连接，但你一直不搭理它，所以服务端的资源也就这么白白浪费掉了。 -
SYN攻击
在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。
SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。
SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了。
使用如下命令可以让之现行：#netstat -nap | grep SYN_RECV - 为什么不能是四次？
四次其实原则上来说是可以的，就是把第二次的ACK和SYN分两次发送。在理论上是完全可以行得通的，但是TCP本着节约网络网络资源的前提。 - 如果双方同时建立连接，会发生什么情况？
这就是双方同时建立链接的情况，情况还不错，反正能建立成功，这点是肯定的。但是要注意两点
第一、此时只会建立一条全双工的TCP链接，不是两条。
第二、双方没有CS之分，两端都是同时承担两个角色，客户端和服务器。 - 为啥要连带发送SYN报文？
TCP是全双工通信，协议规定当收到建立链接请求后必须返回***，同时建立本端到对端的通信链接。这也叫做捎带应答机制。 - 如果第二次报文丢失怎么办？
在发送完ACK+SYN报文后会启动一个定时器，超时没有收到ACK确认，会再次发送，会进行多次重试。超时时间依旧每次翻倍，重试次数可设置。
四次挥手
四次挥手过程
（1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
（2）第二次挥手：服务端接收到客户端的释放请求连接之后，知道客户端没有数据要发给自己了，然后服务端发送ACK = 1告诉客户端受到你发给我的信息，此时服务端处于 CLOSE_WAIT 等待关闭状态。
（3）第三次挥手：此时服务端向客户端把所有的数据发送完了，然后发送一个FIN = 1，用于告诉客户端，服务端的所有数据发送完毕，客户端你也可以关闭接受数据连接了。此时服务端状态处于LAST_ACK状态，来等待确认客户端是否收到了自己的请求。
（4）第四次挥手：此时如果客户端收到了服务端发送完的信息之后，就发送ACK = 1，告诉服务端，客户端已经收到了你的信息。但是我们发现上图中有一个 2 MSL 的延迟等待(第四次挥手的时候客户端有2msl的延迟)。
延申问题
- 为什要有 2 MSL 等待延迟？
对应这样一种情况，最后客户端发送的ACK = 1给服务端的过程中丢失了，服务端没收到，服务端怎么认为的？我已经发送完数据了，怎么客户端没回应我？是不是中途丢失了？然后服务端再次发起断开连接的请求，一个来回就是2MSL，这里的两个来回由那一个来回组成的？
客户端给服务端发送的ACK = 1丢失，服务端等待 1MSL没收到，然后重新发送消息需要1MSL。如果再次接收到服务端的消息，则重启2MSL计时器，发送确认请求。客户端只需等待2MSL，如果没有再次收到服务端的消息，就说明服务端已经接收到自己确认消息；此时双方都关闭的连接，TCP 四次分手完毕。 -
如果双方建立连接，一方出问题怎么办？
如果双方建立连接，但是服务端一直等待接收，发送端出现问题一直不能发送。
所以设计一个保活的计时器，如果一方出现问题，另一方过了这个计时器的时间，就发送试探报文，以后每隔 75 秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。 -
为什么需要四次挥手才能断开链接？
TCP是全双工的通信机制，每个方向必须单独进行关闭。 -
为什么不能用三次握手中捎带应答机制减少一次握手？
TCP是全双工通信的，S收到断开链接请求后只是表示C端不会传输数据到S端了，但是并不表示S端不传输数据到C端。 如果采用捎带应答，S端将无法把剩余的数据传输到C端。