关于网络协议

什么是协议？
协议基本上是双方关于如何进行通信所达成的一致
不同机器中包含的对应层的实体叫做对等进程。在对等进程利用协议进行通信时，实际上并不是直接将数据从一台机器的第N层传送到另一台机器的第N层，而是每一层都把数据连同该层的控制信息打包交给它的下一层，它的下一层把这些内容看做数据，再加上它这一层的控制信息一起交给更下一层，依此类推，直到最下层。最下层是物理介质，它进行实际的通信。相邻层之间有接口，接口定义下层向上层提供的原语操作和服务。相邻层之间要交换信息，对等接口必须有一致同意的规则。层和协议的集合被称为网络体系结构。

网络由下往上分为
物理层、数据链路层、网络层(IP)、传输层(TCP/UDP)、会话层、表示层和应用层(HTTP、FTP、TELNET)。

各协议区别：
1、socket是对TCP/IP协议的封装，socket本身并不是协议，而是一个调用接口(API)
2、传输层的TCP是基于网络层的IP协议的
3、应用层的HTTP协议又是基于传输层的TCP协议的

TCP协议
TCP是面向连接的通信协议，通过三次握手建立连接，通讯完成时要拆除连接，由于TCP是面向连接的所以只能用于端到端的通讯
UDP
UDP是面向无连接的通讯协议，UDP数据包括目的端口号和源端口号信息，由于通讯不需要连接，所以可以实现广播发送。
HTTP连接
HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。
1）在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。
2）在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。
由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种短连接，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次”保持连接”的请求(心跳包)，服务器在收到该请求后对客户端进行回复，表明知道客户端”在线”。若服务器长时间无法收到客户端的请求，则认为客户端”下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。

TCP三次握手建立连接：
tcp标志位有6种：SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)Sequence number(顺序号码) Acknowledge number(确认号码)
第一次握手：主机A发送位码为syn＝1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；
第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包
第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。
完成三次握手，主机A与主机B开始传送数据。
TCP四次挥手断开连接
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。
（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。
（3） 服务器关闭客户端的连接，发送一个FIN给客户端。
（4） 客户段发回ACK报文确认，并将确认序号设置为收到序号加1。

TCP超时重传机制
超时重传是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。
参考连接：
http://baike.baidu.com/view/4330519.htm
http://weibo.com/p/1001603821691477346388?sudaref=mail.qq.com

为什么必须三次建立连接|如果为两次可能引发的问题？
1、针对已失效的连接请求
client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了
(我们知道客户端在调用connect函数之后进入了SYN_SEND状态，只有接收到服务器端的SYN+ACK包才进入ESTABLISHED状态。因为对于已经失效的连接请求报文，由于此时客户端没有进入SYN_SEND状态，而处于CLOSED状态，即使收到服务器端的SYN+ACK包，也不会产生任何状态变化，也就不会理踩server的确认和发送ack包了；
上面的解释仅仅是假设客户端处于CLOSED状态时废弃包的到来，并没有对客户端处于非CLOSED状态时废弃包的到来进行分析，好歹通过google，得到了非CLOSED状态下为什么两次握手可能会出现的问题，这里也分两种情况，一种是废弃的报文的干扰，一种是废弃的SYN报文的干扰。)
2、死锁
假定client给server发送一个连接请求分组，server收到了这个分组，并发送了确认应答分组。按照两次握手的协定，server认为连接已经成功地建立了，可以开始发送数据分组。可是，client在server的应答分组在传输中被丢失的情况下，将不知道server是否已准备好，不知道server建立什么样的序列号，client甚至怀疑server是否收到自己的连接请求分组。在这种情况下，client认为连接还未建立成功，将忽略server发来的任何数据分组，只等待连接确认应答分组。而server在发出的分组超时后，重复发送同样的分组。这样就形成了死锁
(这个答案有点牵强，毕竟现在tcp传输机制中都有定时器，会有超时重传，不会导致死锁的，当然如果没有超时机制，死锁还是可能的；
server超时重传，难道client没有收到server的ACK信号，不会重新发送SYN信号么？ 只要重新发送SYN，server端自然也会发送确认应答分组，这样就不会导致死锁）

参考连接：
http://bbs.csdn.net/topics/390706512
http://my.oschina.net/xiaot99/blog?disp=2&p=1&catalog=443547