【知识详解】传输层详解(秋招总结)
传输层详解
1.传输层概述
1.1 概述
TCP隶属于传输层，所以要首先明白传输层的作用是什么，传输层能够实现端到端的连接。比如说我们用QQ与别人发信息，网络层能够将信息发送到对方的主机上，主机上使用什么协议来接受这个信息就由传输层来完成，所以传输层实现的是进程到进程间的连接。
传输层提供的是应用程序间的逻辑通信，也就是说它向高层(应用层)屏蔽了下面网络层的细节，使应用程序看起来好像是在传输层之间沿着水平方向传输数据，但事实上两者之间并没有这样一条实际的物理连接。
1.2 功能
- 1.网络层提供了点到点的连接，而传输层提供了端到端的服务，也就是进程间的通信；
- 2.网络层提供的是不可靠的连接，传输层能够实现可靠的传输；
1.3 协议
- TCP(Transmission Control：Protocol) 传输控制协议
- UDP(User Datagram Protocol) 用户数据报协议
1.4 传输层和应用层的关系
1.4.1 端口
TCP/IP传输层用一个16位端口号(0~65535)来标识一个端口，但是注意，端口号只具有本地意义，不同计算机的相同端口号没有关联，0一般不用，所以允许有65535个不同的端口号。
两个计算机的进程要实现通信，不仅必须知道对方的IP地址(为了找到对方的计算机)，而且还要知道对方的端口号(为了找到对方计算机中的应用程序)
问：怎么理解端口？
在网络技术中，端口(Port)大致有两种意思：
1.硬件端口，也就是设备间交互的接口，是物理意义上的端口，比如集线器，交换机等设备的接口；
2.软件端口，指的是应用层的的进程和运输层进行层间交互的一种地址，是逻辑意义上的端口，一般指的是TCP/IP协议中的端口。正是这种端口，所有传输层实现的是端到端的通信；
在TCP/IP协议中，用"源IP地址、目的IP地址、源端口号、目的端口号、协议号"这五部分组成一个套接字，来标识一次通信；
- 一个进程可以绑定多个端口号，因为一个进程可以有很多线程或者说是子进程等，这每一个都对应一个端口号，所以一个进程可以绑定多个端口号；
- 但是一个端口号不可以被多个进程绑定，每一个端口号都与唯一的进程对应，if有多个了，那通信不就乱了套了吗；
一个端口号一个进程，一个进程可以多个端口；
端口号分类
- 公认端口：0~1023，明确与某种服务绑定，比如各种协议；
- 注册端口：1024~65535：松散的绑定一些服务，也就是有许多服务绑定这些端口。
TCP/UDP加上特定的端口号就可以表示应用层的某个协议；
问：知道哪些常用的端口号
- TCP+20/21: ftp协议(文件传输协议)；
- TCP+22: ssh协议(专门为远程登录提供的安全性协议)
- TCP+25: SMTP协议(简单邮件传输协议)
- TCP/UDP+53: DNS协议(域名解析协议)
- TCP+80: Http协议(超文本传输协议)
- TCP+443: Https协议(超文本传输安全协议)
2.TCP协议
一个TCP连接不仅需要端口，还需要IP地址来确定通信的主机。所以IP首部中的发
送端IP地址加上发送端端口号就形成了连接的发送端；目标端IP地址再加上接收端端口号
就确定了连接的接收端。这样就唯一地确定了一个TCP连接。
在TCP/IP协议中，TCP协议是基于IP协议的。IP协议是对应于网络层的协议，它是
一个不可靠的协议。TCP协议的可靠性保证给IP协议提供了可靠环境，从而使得IP协议可以不必考虑传输的可靠性，专注于网络层的功能。这也是协议分层的初衷。
IP协议解决了数据包的路由和传输，上层的TCP就可以不再关注路由和寻址；TCP协议解决了传输的可靠性和顺序问题，上层的应用层就可以直接使用TCP协议进行数据传输，不再需要关心数据段的丢失和重复
http是要基于TCP连接基础上的，简单的说，TCP就是单纯的简历连接，不涉及任何我们需要请求的数据；http协议使用来收发数据，就是为实际应用而来的；
TCP被认为是一种流式传输层服务。它表示TCP发送端从应用程序接收到字符流，并从这个流中提取适当的长度创建数据段，然后将其发送到网络上。TCP接收端则接收数据段，从中提取数据，若没有按序号到达还要对其进行排序，并将其作为字符流交付给接收端应用程序。这样就完成了数据的传输。
下图是一张典型的TCP面向流的传输
问：TCP怎样实现可靠传输？
TCP采用了很多手段来保证可靠传输
- 1.连接管理机制：在传输数据前需要进行建立连接,也就是三次握手，在数据传送完后还需要释放连接，也就是四次挥手。
- 2.数据分段：TCP以报文段为单位进行发送，在建立TCP连接的时候，两端协商TCP报文段中的数据字段(也称为数据包)的最大长度(MSS);其长度加上首部长度就是整个TCP报文段的长度；
- 3.校验和：提供了一种简单的校验，如果收到段的校验和和原来的有差别，那接收方就会丢掉这个报文段；
- 4.序列号：TCP给发送的数据包的编号，如果接收端收到乱序后会进行重新排序，收到重复的也会进行丢弃；
- 5.确认应答：接收方收到报文后会回复确认(累计确认：对所有收到的按序的只确认最后，确认号之前的数据已经全部收到了)；
- 6.重发控制：TCP发出一个报文段后，就会启动一个定时器，等接收方确认这个报文段，如果不能及时收到确认，将重发这个报文段；
- 7.流量控制：通信的双方都有固定大小的缓冲区，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，就把窗口缩小，并把窗口值告诉发送端（提示发送方降低发送的速率，防止包丢失）是利用滑动窗口来实现；
- 8.拥塞控制：当网络产生拥堵时，减少数据的发送；主要是通过拥塞窗口来实现；(慢开始和拥塞避免；快重传和快恢复)；
问：什么是TCP粘包？怎么解决？
socket网络编程中，都是端到端的通信，需要有客户端端口+服务端端口+客户端ip+服务端ip+传输协议这五部分来确定一个明确的连接；
发送方为了更高效的发送数据给，会采用优化算法，比如每次将间隔较小，数据量较小的数据，合并成一个大的数据库，然后再进行封包；所以在接收端就需要对这个封包进行拆包；
TCP粘包：TCP粘包是指发送方发送的数据在到达接收端后粘到了一包，也就是一条数据的头紧接着另一条数据的尾。
造成TCP粘包的原因：
- 发送方使用了优化算法，也就是将数据进行合并后进行发送，可能会造成粘包问题；
- 接收方在收到数据后，并不马上交给应用层，而是将数据放到接收缓存中，所以应用层读的时候就可能读到多个首尾相连的数据；
什么时候需要处理粘包？
- if发送方发送的数据本身就是同一块数据的不同部分，比如一个文件的多个部分，这时候不需要处理粘包；
- if这里面的多个分组毫不相关，或者说是并列的，那就不需要处理粘包问题；
- if双方建立连接后，需要在一段时间里发送不同的结构数据，那就需要处理粘包问题；
解决方法
解决的总体思路就是我们要知道每一条数据的长度：
- 格式化数据：在数据上添加固定的开始和结束标志，这种方法很简单，但是在数据内部不能有开始和结束符合；
- 发送长度，也就是在每一条数据上都添加数据的长度，然后应用层就可以根据长度来读取数据；
TCP才会产生粘包现象，然后UDP不会产生粘包现象，因为UDP是面向报文的，每次都发送一条独立的消息。
2.1 TCP首部
TCP首部默认有20个字节的固定首部。从下图也能看到，4*5=20；以下是首各内容的含义
- 源端口和目的端口：各占两个字节；(16bit的端口号+32bit的ip地址形成了一个套接字socket，每一条TCP连接唯一的被两端的两个端点也就是两个套接字确认，所以这也构成了传输层的点到点通信)
- 序号(seq)：占4个字节；(在传输的数据中，每一个字节都有一个序号，这个序号就是本次传输数据的第一个字节的序号)；
- 确认号(ack)：占4个字节；(这个值是代表期待收到对方下次发送的数据的第一个字节的序号，比如如果发送ack=301，则表示前300个我收到了，下次你给我发第301个)；
- 数据偏移：占4位，也叫首部长度(Header length),一般情况下首部长度是20字节，但是也可以扩展，比如这4位都置为1时十进制是15，代表可以首部可以有15行，一行4个字节，所以是60个字节；
- 6个控制位
URG:紧急指针有效位，和第5行的紧急指针一起用，可以让紧急数据进行加塞，接收端可以优先快速的获取紧急数据；
ACK:指示ack确认号是否有效；
PSH:置为1时表示将本报文段立即向上交付有应用层，而不用等缓存填满再交付；
RST:置为1时通知重新建立TCP连接；
SYN:同步序号位，置为1表示需要建立连接；比如SYN=1,ACK=0时表明是一个连接建立请求；而SYN=1,ACK=1,表明是一个连接接受请求；
FIN:置为1时表明发送数据结束，连接释放；
- 窗口：占2个字节：用来说明本地可以接收的数据段的数目，以字节为单位，流量控制就是基于这个窗口来实现的，其大小是可变的；
- 检验和：占2个字节：用来做差错控制，在发送端计算一次所有数据的检验和，在接收端再计算一次，一致则说明数据基本正确；
- 紧急窗口：和URG配合使用；
2.2 连接管理机制
三次握手
- 第一次握手：SYN=1，seq=x，进入SYN-SENT状态，等待确认；
- 第二次握手：SYN=1, ACK=1, seq=y, ack=x+1(确认对方的，发送自己)，进入SYN-RECV状态；
- 第三次握手：ACK=1, seq=x+1, ack=y+1(确认对方，发送自己)，客户端服务器进入ESTABLISHED状态；
问：为什么是三次握手？**
本质上是为了在不可靠的信道建立可靠的连接，防止已经失效的报文突然又到了服务器，假设客户端发送了一个请求连接，但是因为信道的原因发生了滞留，等了一会没有收到确认，再次发送请求连接，这次信道情况较好，很快进行了确认接受了连接，但是过了一会那个滞留的连接到达服务器，其实已经是一个失效的报文了，服务器以为客户端再次发起新的连接，回复确认。如果采用两次握手，服务器发出确认后就建立了连接，但是客户端并没有发出连接的请求，所以不会理睬服务器的确认，那这样服务器认为连接已经建立，一直等待客户端发送数据，造成资源的浪费。如果是三次握手的话，服务器会等着客户端的确认，如果收不到确认，就知道客户端并没有想建立连接。
问：如果第三次客户端发送的ACK丢失，客户端和服务端分别会是什么反映？
服务端：
这时候的服务端处于SYN-RECV(同步收到)状态，如果没有收到客户端的ACK确认，会根据TCP的超时重传机制，等待一定时间(3秒、6秒)后重新发送SYN+ACK包。服务断重发一定次数后(默认是5)，如果仍然没有收到客户端的ACK，那服务器就把这个连接关闭。
客户端：
这时候客户端的状态已经是ESTABLISHED(已连接)状态了，如果这时候发出的ACK包丢失了，客户端向服务端发送数据，服务端将以RST包响应(上面介绍过RST标志位)，要求重新建立连接。
问：TCP连接建立的三次握手过程可以携带数据吗？
我自己感觉首先携带SYN标志的是不可以携带数据的，也就是三次握手的前两次，这时候连接还没建立呢，感觉是不可以携带数据的。 比如说，if第一次握手就可以携带数据，那要是有人要恶意攻击服务器，每次在第一次握手的SYN报文中就放入大量的数据，攻击的人是不会理睬服务器是否可以正常接收的，这样服务器就会花很长时间和内存去处理接收这些报文；也就是第一次握手会让服务器容易受到攻击；
第三次握手也就是ACK包是可以携带数据的，这个时候客户端自己已经是连接建立的状态了，而且也知道服务器的接收、发送功能是正常的，所以我感觉在第三次是可以携带的；
问：在TCP连接建立的过程中，会不会受到攻击(SYN攻击/Dos攻击)？
SYN洪泛攻击就是说客户端在短时间内伪造大量不存在的ip地址，然后不停的向服务器发送SYN包，然后服务器就需要一一回复确认包，并等待客户端的一个确认；但是原ip地址并不存在，那服务器就得不到回应，就会不断超时重传然后直到超时，这些伪造的SYN包会占用连接队列，导致正常的SYN请求进不来了，所以就会导致网络拥塞甚至系统瘫痪，这就是一种典型的Dos/DDos攻击；
DDos攻击：客户端向服务器发送大量请求连接，服务器因此分配连接资源，然后向客户端发送第二次握手数据包，但是这时候客户端不发送第三次握手数据包，那服务器的资源就等着第三次的握手数据包，这样服务器的资源被大量占用，导致性能下降；
目前没有根治的办法，只能预防：比如正确设置防火墙，限制某些ip地址的访问，缩短等待时间等；
四次挥手
- 1.客户端发出连接释放报文，停止发送数据，FIN=1,seq=u(等于前面传过来的最后一个序列号+1，TCP规定FIN报文段即使不携带数据，也消耗一个序号)，此时客户端进入FIN-WAIT-1(终止等待1)状态。
- 2.服务器收到连接释放报文，发出报文确认，ACK=1,ack=u+1，并且带上自己的序列号，seq=v，此时服务器进入CLOSE-WAIT状态，这时候客户端不发了，但是服务端还要发，客户端依然要接收。客户端收到确认请求后，进入FIN-WAIT-2(终止等待2)状态，等待服务器发送连接释放报文。
- 3.服务器发送完毕后，向客户端发送连接释放报文，FIN=1,ACK=1,ack=u+1,seq=w，此时，服务器进入LAST-WAIT(最后确认)状态，等待客户端确认。
- 4.客户端收到连接释放报文，发出报文确认，ACK=1,ack=w+1，自己的序列号仍是seq=u+1，此时，客户端进入TIME-WAIT(时间等待)状态，注意此时TCP连接没有释放，必须等待2MSL(最长报文段寿命)时间后，才会进入CLOSE(关闭)状态。服务器只要收到了确认后，立马进入CLOSED状态。所以服务器结束时间要比客户端早一些。
问：为什么握手是三次而挥手是四次？
因为服务器收到客户端的SYN连接建立报文后，可以直接发送SYN+ACK报文，即应答和同步，但是在关闭连接时，服务器可能还有数据要发送，所以只回复一个应答告诉客户端自己收到了，但是我这不能关，得等我发完了，我才能发送FIN连接释放报文。
问：为什么TIME-WAIT需要2MSL才能返回CLOSE状态？
因为信道是不可靠的，最后一个ACK确认报文发送后可能会丢失，服务器如果没有收到ACK确认，就会重发FIN连接释放报文，如果客户端又收到了，那就知道刚才那个确认丢失了，重发ACK确认。所以，当客户端在2MSL时间内没有再次收到FIN报文后，客户端就知道服务器已经成功收到了，进入CLOSED状态。
2.3 确认应答机制(ACK机制)
TCP将每个字节都进行了编号，也就是序列号
每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你要从哪里开始发.
比如, 客户端向服务器发送了1005字节的数据, 服务器返回给客户端的确认序号是1003, 那么说明服务器只收到了1-1002的数据.
1003, 1004, 1005都没收到.
此时客户端就会从1003开始重发.
2.4 流量控制机制
流量控制：流量控制就是让发送方的发送速率不要太快，要让接收方来得及处理。TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，就把窗口缩小，并把窗口window值告诉发送端（提示发送方降低发送的速率，防止包丢失）。
TCP使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量控制，随ACK报文发送)，所以首先来看一下滑动窗口
滑动窗口
刚才说了确认应答机制，但是想一下，如果每发送一个数据段都要发送一个ACK确认应答后才能发送下一个数据段，那这样性能就会很低，吞吐量也很低。所以引入了窗口。
窗口：窗口大小就是指无需等待确认就可以继续发送数据的最大值。
- A的发送窗口和B的接受窗口都是20个字节。
- 只要是在窗口之内的，那A就可以不用等着确认就可以发送，比如即使红色部分都没有收到确认，但是后面的42也都可以发送，解决吞吐量的问题。
- 当B给了A一个确认后，比如过了一会给了确认号34，那就表明34之前的都已经收到了，那A的发送窗口就可以向前滑动了，滑到34位置，然后后面的新到了窗口里的字节(51-53)就可以接着发送。
- 凡是在发送窗口里的都可以直接发送，移出窗口外的就是已经完全被接收端接收好了的。
- 如果这时候发生了丢包怎么处理呢，两种情况：
- 1.数据包收到了，但是确认应答丢了，比如B发送了确认34，但是丢了，然后B又发送确认45，这时候没丢，那其实丢失了一部分ACK并没有太大关系，因为能够通过后面没丢的ACK来确认已经收到了哪些数据包。
- 2.数据包丢了，比如A发送了31-33，接着发34-41，接着发42-46，但是34-41这个数据段丢了，B没收到，那就发送ack=34，而且会连续发3次，为什么要3次呢，因为如果只发一次不一定丢了，B的确认比A慢一点。你看上面的例子A都发完50了，B可能才确认到34。发3次后，就像是在提醒A：我要的是34。然后发送端就会把34-41重传，注意后面的42-46不会重发(选择确认SACK);
流量控制
接收端根据自己的窗口大小，来告诉发送方的发送速率。
- 接收端通过将自己的窗口大小放入首部中的“窗口大小”字段，然后通过ack报文通知客户端。
- 发送端根据这个大小来调整自己的发送速度。如果接收区满了，那就将窗口设置为0，这时发送端不再发送，然后定期通过一个窗口探测来试探接收端的窗口大小。
2.5 拥塞控制机制
有了滑动窗口后，TCP就可以高效的发送大量数据了，但是想一下，如果我们上来就发送大量数据，网络上的其他计算机、网络状况都不清楚，就有可能会堵塞。所以TCP引入了拥塞控制机制。
拥塞控制：就是当网络产生拥塞时，减少数据的发送。
拥塞产生的条件：对资源需求的总和 > 可用资源
拥塞控制归根结底就是TCP协议想尽可能的把数据传输给对方，但是又要避免网络压力太大出现拥堵的折中方案。
问：流量控制和拥塞控制有什么区别？
流量控制是端到端的控制，是通信双方的一种控制，就是要抑制发送方的速度使接收方能够来得及接收和处理，采用滑动窗口来实现。
拥塞控制是解决网络的拥堵问题，它涉及到的不仅是通信的双方，而是涉及到网络上所有的主机、路由器，所以这是一个全局性的过程。
拥塞窗口：TCP中维持一个叫做拥塞窗口(cwnd)的变量。这个窗口根据网络状况动态变化。
- 只要网络没有出现拥塞，就把cwnd增大一点，为了能够把数据更快发送出去；
- 只要网络出现拥堵，就把cwnd减少一点，为了减缓网络的压力；
- 网络中实际的发送窗口大小应该是接收窗口和拥塞窗口的较小一个，即发送窗口 = min[rwnd, cwnd]; 当cwnd较小时，拥塞窗口限制着发送速度，当rwnd较小时，接收窗口限制着发送速度；
慢开始和拥塞避免
- 慢开始：刚开始设置cwnd为1，然后每经过一个传输轮次，cwnd就加倍；
- 慢开始门限：当cwnd < 慢开始门限时，使用慢开始算法，也就是指数增长；
当cwnd > 慢开始门限时，改用拥塞避免算法，也就是加法增大
(慢开始门限就是图中的16)； - 拥塞避免：让拥塞窗口缓慢增大，不再是加倍了，而是线性规律缓慢增长(就是想让网络不容易出现拥塞)，这也叫做加法增大；
- 当网络拥堵时(比如图中的24)，执行两步动作：
- 慢开始门限设置为出现拥塞的窗口的一半(变为12)， 这也叫乘法减小
- 将cwnd设置为1，重新执行慢开始算法；
这样做就是想迅速减少网络的拥堵，让网络能够把拥塞的报文先处理了；
快重传和快恢复
在没有快重传时，如果一个数据段丢失了，会等待一定的超时周期才重传(每发送一个数据段之后就会启动一个计时器)，这增加了时延；
- 接收端收到A的1报文后，发送ACK2,然后2丢失，接收端会连发3个ACK2，这时候发送端会立即重传2，而不用管计数器了。
- 如果打开了SACK(选择确认)，那后面我们正常收到的，比如3会放在缓冲区里，就不用再次重传了，包括后面的5-11，都不会再次重传，只会重传丢失的数据包，但是如果没有打开SACK，就会把2后面的所有数据段都进行重传；
问：为什么会选择3次呢？**
首先要明白这个3次指的是3次冗余，是不包括前面的正常确认的。
原因就是因为网络传输是不可靠的，在将不同数据段发送的时候，可能会导致到达接收端的顺序是不一样的，也就是乱序，比如后面的N+1到了，N+2到了，但是N没到，那这时候可能等一等一会就到了，也可能就是丢了，在发3次的时候A丢包的可能性是最高的。所以选择3，其实在实际抓包的时候，快重传都会在大于3后发生；
- 当收到3个连续的重复确认后，A其实并不能判断是否拥塞，丢包了，好像拥塞了，但是B的3次确认又都能收到，又好像没堵。
- 快恢复和前面的区别就在于当执行快重传算法后，同样将慢开始门限设为当前窗口的一半，但是不再重新慢开始了，而是直接从新的慢开始门限开始执行拥塞避免，也就是加法增大。这样提高了恢复速度。
3. UDP协议
3.1 UDP首部
UDP首部默认是8个字节的固定长度。
- 源端口和目的端口：各占两个字节；(16bit的端口号+32bit的ip地址形成了一个套接字socket，每一条TCP连接唯一的被两端的两个端点也就是两个套接字确认，所以这也构成了传输层的点到点通信)
- 长度：占2个字节，是UDP数据报的长度(包括首部和数据),最小为8，只有首部；
- 校验和：占2个字节，是可选的，提供简单的校验。这是UDP提供的唯一可靠机制。
3.2 UDP的特点
有时候TCP显得不太合适，比如说要发送一个4个字节的数据，如果使用TCP，就要给其加上至少20字节的头部信息，而且还要确认，时间大大降低。所以在传输效率高的时候用UDP，其只需要8个字节的首部，而且不需要确认。
UDP是面向报文的，应用层交下来的报文，不合并也不拆分，添加UDP首部后就直接向下交付给IP层，也就是一次发送一个报文；
UDP在传送数据之前不需要建立连接，收到后也不需要给出确认，所以没有办法保证可靠交付。
4. TCP和UDP的区别
两者类似于打电话和写信的区别，两个人打电话时，双方需要确认并建立连接才能通信。 在邮局寄信时，只需要将信放信箱就行了，不用告诉对方。
问：TCP和UDP的特点和区别？
- 1.两者所有的区别都是因为两者的目的是不同的，TCP目的是提供可靠的数据传输，所以其采用了很多措施来达到这一目的，比如连接管理，确认机制，流量控制，拥塞控制等等，但是UDP并不一定提供可靠的交付，它提供的最大努力的交付，并不一定保证传输过去后是准确无误的，它是想尽可能快的传送尽可能多的信息(比如说像即时通信)；
- 2.正是因为上面说的两者的目的不同，所以有了很多具体的区别。
- 比如TCP是面向连接的，在传输数据之前需要先建立连接，数据发送完毕后也需要关闭连接，而UDP不需要连接。
- 比如TCP是面向字节流的，而UDP是面向报文的。
- 比如TCP需要有确认应答机制，而UDP不需要。
问：TCP的面向字节流和UDP的面向报文怎么理解？
- TCP是面向字节流的协议，也就是说数据是以字节流的形式传递给对方的，没有固定的报文或者说报文边界概念。双方都会有一个缓冲区，如果字节流太长，TCP就会拆分进行发送，如果字节流很短，那也可以等着缓冲区中的字节流变长了以后再构成一个报文段进行发送。
- UDP是面向报文的协议，应用层交给UDP多长的协议，就发送多长的报文，不合并也不拆分，保留报文的边界，一次发送一个。
问：基于TCP和UDP的应用层协议有哪些？
- 基于TCP的：HTTP、HTTPS、FTP、SSH；
- 基于UDP的：DNS、TFTP(简单文件传输协议，端口69)；
问：QQ或者微信聊天是采用什么协议？
- TCP的应用场景：文件的上传和下载、浏览器上网、绝大多数应用都是TCP；
- UDP的引用场景：音视频传输(qq和微信)、共享屏幕等；
QQ和微信主要是采用UDP的方法，主要是因为效率高、传输快，占用资源少，但是主要是不可靠，所以很多时候会辅助一些算法来保证可靠传输；在qq里，一台服务器要容纳十几万的并发连接，所以if都是去进行建立连接这样的过程效率太低，太影响信息传输的效率，所以采用了UDP协议；它们应该是在上层采用了一些算法来实现可靠，比如if客户端使用UDP协议发出消息后，if服务器收到该包，那就需要使用UDP协议发回一个应答包，用这样的方法实现可靠传输；
