一、请简述TCP\UDP的区别
TCP和UDP是OSI模型中的运输层中的协议。TCP提供可靠的通信传输，而UDP则常被用于让广播和细节控制交给应用的通信传输（例如QQ）。
两者的区别大致如下：
- TCP面向连接，UDP面向非连接即发送数据前不需要建立链接
- TCP提供可靠的服务（数据传输），UDP无法保证
- TCP面向字节流，UDP面向报文
- TCP数据传输慢，UDP数据传输快
二、浏览器输入URL后的过程
- 1、客户端浏览器通过DNS解析到http:/ /www.baidu.com的IP地址220.181.27.48，通过这个IP地址找到客户端到服务器的路径。客户端浏览器发起一个HTTP会话到220.161.27.48，然后通过TCP进行封装数据包，输入到网络层。
- 2、在客户端的传输层，把HTTP会话请求分成报文段，添加源和目的端口，如服务器使用80端口监听客户端的请求，客户端由系统随机选择一个端口如5000，与服务器进行交换，服务器把相应的请求返回给客户端的5000端口。然后使用IP层的IP地址查找目的端。
- 3、客户端的网络层不用关系应用层或者传输层的东西，主要做的是通过查找路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的工作，我不作过多的描述，无非就是通过查找路由表决定通过那个路径到达服务器。
- 4、客户端的链路层，包通过链路层发送到路由器，通过邻居协议查找给定IP地址的MAC地址，然后发送ARP请求查找目的地址，如果得到回应后就可以使用ARP的请求应答交换的IP数据包现在就可以传输了，然后发送IP数据包到达服务器的地址。
三、简单解释一些ARP协议的工作过程
- 首先，每个主机都会在自己的 ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址之间的对应关系。
- 当源主机要发送数据时，首先检查ARP列表中是否有对应IP地址的目的主机的MAC地址，如果有，则直接发送数据，如果没有，就向本网段的所有主机发送ARP数据包，该数据包包括的内容有:源主机IP地址，源主机MAC地址，目的主机的IP地址。
- 当本网络的所有主机收到该ARP数据包时，首先检查数据包中的IP地址是否是自己的IP地址，如果不是，则忽略该数据包，如果是，则首先从数据包中取出源主机的IP和MAC地址写入到ARP列表中，如果已经存在，则覆盖，然后将自己的MAC地址写入 ARP响应包中，告诉源主机自己是它想要找的MAC地址。
- 源主机收到ARP响应包后。将目的主机的IP和 MAC地址写入ARP列表，并利用此信息发送数据。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。
四、OSI七层结构图
五、HTTP协议的几种请求方式
常用HTTP请求有GET和POST两种。
GET
??对服务器资源的简单请求
???GET方法是默认的HTTP请求方法，我们日常用GET方法来提交表单数据，然而用GET方法提交的表单数据只经过了简单的编码，同时它将作为URL的一部分向Web服务器发送，因此，如果使用GET方法来提交表单数据就存在着安全隐患上。例如
Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=�%E+��
???从上面的URL请求中，很容易就可以辩认出表单提交的内容。（？之后的内容）另外由于GET方法提交的数据是作为URL请求的一部分所以提交的数据量不能太大
POST
???用于发送包含用户提交数据的请求
???POST方法是GET方法的一个替代方法，它主要是向Web服务器提交表单数据，尤其是大批量的数据。POST方法克服了GET方法的一些缺点。通过POST方法提交表单数据时，数据不是作为URL请求的一部分而是作为标准数据传送给Web服务器，这就克服了GET方法中的信息无法保密和数据量太小的缺点。因此，出于安全的考虑以及对用户隐私的尊重，通常表单提交时采用POST方法。
???? 从编程的角度来讲，如果用户通过GET方法提交数据，则数据存放在QUERY＿STRING环境变量中，而POST方法提交的数据则可以从标准输入流中获取。
六、三次握手、四次挥手
三次挥手
详解请见：续篇（ 一） TCP 为什么是三次握手，四次挥手？
四次挥手
第一次挥手： 客户端发送发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据,主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
第二次挥手： 服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
第三次挥手： 服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
第四次挥手： 客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。
收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。
四次挥手释放连接时，等待2MSL的意义?
MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。
两个理由：
- 保证客户端发送的最后一个ACK报文段能够到达服务端。
- 防止“已失效的连接请求报文段”出现在本连接中。
SYN攻击
????服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。
???检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。
netstat -n -p TCP | grep SYN_RECV
常见的防御 SYN 攻击的方法有如下几种：
- 缩短超时（SYN Timeout）时间
- 增加最大半连接数
- 过滤网关防护
- SYN cookies技术
七、差错检测
TCP怎么保证错误重传？
（1）接收方收到错误的分组，就直接丢弃，而不做任何操作。
（2）发送方在规定的时间（比平均往返时延大一些）没有收到分组的确认分组，就会自动重传。
（3）当然，为了让对方知道哪个分组出问题了，就也为分组编了序号。
IP协议的差错检测：
（1）检测哪一部分？ IP协议只检测IP数据报的首部，不检测数据部分。
（2）由谁检测？ 数据报每经过一个路由器，路由器都进行一次差错检测。
（3）错误之后怎么办？ 路由器发现数据报错误后，直接丢弃。
（4）怎么检测？ 不使用复杂的CRC检验，利用IP数据报中的首部检验和。
方法：16个二进制一组，之后求反码相加。
（5）检测过程：
-
发送方：把IP数据报首部分成16位的序列，之后每一个序列进行求反码在求和。并把和的反码放入首部检验和。
-
接收方（经过的路由器）：把IP数据报首部分成16位的序列，之后每一个序列进行求反码在求和。之后再与首部检验和相加，为0则正常。不为0则出错。
UDP协议的差错检测：
（1）检测哪一部分？ UDP协议检测整个用户数据报（首部 + 数据部分）
（2）由谁检测？ 由目的主机检测
（3）错误之后怎么办？ 目的主机发现数据报错误后，直接丢弃。
（4）怎么检测？ 不使用复杂的CRC检验，和IP数据报的检测方法相似。
方法：伪首部 + 首部 + 数据部分 + 全0的填充字节 + 16个二进制一组，之后求反码相加。
使用伪首部的原因：只是单纯为了做校验用的。
伪首部包括：伪首部包含源IP地址和目的IP地址，UDP协议号以及UDP长度等信息，目的是让UDP两次检查数据是否已经正确到达目的地。
注意：
1、 伪首部不上传也不想下传输。
2、 由于检测的部分可能不是偶数个字节，不能均拆成16位的序列，此时可以插入全0的填充字节。
（5）检测过程：
-
发送方：把待检测的部分分成16位的序列，之后每一个序列进行求反码在求和。并把和的反码放入首部检验和。
-
接收方：把待检测的部分分成16位的序列，之后每一个序列进行求反码在求和。之后再与首部检验和相加，为0则正常。不为0则出错。
TCP协议的差错检测：
（1）检测哪一部分？ TCP协议检测整个用户数据报（首部 + 数据部分）
（2）由谁检测？ 由目的主机检测
（3）错误之后怎么办？ 目的主机发现数据报错误后，直接丢弃。
（4）怎么检测？ 不使用复杂的CRC检验，和IP数据报的检测方法相似。
方法： 伪首部 + 首部 + 数据部分 + 全0的填充字节 + 16个二进制一组，之后求反码相加。
使用伪首部的原因： 只是单纯为了做校验用的。
伪首部包括： 伪首部包含源IP地址和目的IP地址，TCP协议号以及TCP长度等信息，目的是让TCP两次检查数据是否已经正确到达目的地。
注意：
<1> 伪首部不上传也不想下传输。
<2> 由于检测的部分可能不是偶数个字节，不能均拆成16位的序列，此时可以插入全0的填充字节。
（5）检测过程：
-
发送方： 把待检测的部分分成16位的序列，之后每一个序列进行求反码在求和。并把和的反码放入首部检验和。
-
接收方： 把待检测的部分分成16位的序列，之后每一个序列进行求反码在求和。之后再与首部检验和相加，为0则正常。不为0则出错。
记忆：
（1）IP协议只检测首部，而TCP和UDP检测整个首部和数据部分，当然还包括伪首部。
（2）IP、UDP、TCP检测出错误后，会直接丢弃。但是TCP协议会要求重传。
（3）UDP和TCP的差错检测方法一样。
（4）伪首部不上传也不想下传输。