Android Socket使用详解

• “已失效的连接请求报文段”的产生在这样一种情况下：Client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。
• 这是一个早已失效的报文段。但Server收到此失效的连接请求报文段后，就误认为是Client再次发出的一个新的连接请求。
• 于是就向Client发出确认报文段，同意建立连接。
• 假设不采用“三次握手”：只要Server发出确认，新的连接就建立了。
• 由于现在Client并没有发出建立连接的请求，因此不会向Server发送数据。
• 但Server却以为新的运输连接已经建立，并一直等待Client发来数据。>- 这样，Server的资源就白白浪费掉了。

采用“三次握手”的办法可以防止上述现象发生：

• Client不会向Server的确认发出确认

• Server由于收不到确认，就知道Client并没有要求建立连接

• 所以Server不会等待Client发送数据，资源就没有被浪费

• TCP释放连接
  TCP释放连接需要四次挥手过程，现在假设A主动释放连接：（数据传输结束后，通信的双方都可释放连接）

• 第一次挥手：A发送释放信息到B；（发出去之后，A->B发送数据这条路径就断了）

• 第二次挥手：B收到A的释放信息之后，回复确认释放的信息：我同意你的释放连接请求

• 第三次挥手：B发送“请求释放连接“信息给A

• 第四次挥手：A收到B发送的信息后向B发送确认释放信息：我同意你的释放连接请求

B收到确认信息后就会正式关闭连接； A等待2MSL后依然没有收到回复，则证明B端已正常关闭，于是A关闭连接

为什么TCP释放连接需要四次挥手？

为了保证双方都能通知对方“需要释放连接”，即在释放连接后都无法接收或发送消息给对方

• 需要明确的是：TCP是全双工模式，这意味着是双向都可以发送、接收的
• 释放连接的定义是：双方都无法接收或发送消息给对方，是双向的
• 当主机1发出“释放连接请求”（FIN报文段）时，只是表示主机1已经没有数据要发送 / 数据已经全部发送完毕；

但是，这个时候主机1还是可以接受来自主机2的数据。

• 当主机2返回“确认释放连接”信息（ACK报文段）时，表示它已经知道主机1没有数据发送了
  但此时主机2还是可以发送数据给主机1
• 当主机2也发送了FIN报文段时，即告诉主机1我也没有数据要发送了
  此时，主机1和2已经无法进行通信：主机1无法发送数据给主机2，主机2也无法发送数据给主机1，此时，TCP的连接才算释放

1.5 UDP协议

• 定义：User Datagram Protocol，即用户数据报协议，是一种传输层通信协议。

基于UDP的应用层协议有TFTP、SNMP与DNS。

• 特点：无连接的、不可靠的、面向报文、没有拥塞控制

• 无连接的：和TCP要建立连接不同，UDP传输数据不需要建立连接，就像写信，在信封写上收信人名称、地址就可以交给邮局发送了，至于能不能送到，就要看邮局的送信能力和送信过程的困难程度了。

• 不可靠的：因为UDP发出去的数据包发出去就不管了，不管它会不会到达，所以很可能会出现丢包现象，使传输的数据出错。

• 面向报文：数据报文，就相当于一个数据包，应用层交给UDP多大的数据包，UDP就照样发送，不会像TCP那样拆分。

• 没有拥塞控制：拥塞，是指到达通信子网中某一部分的分组数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿，即出现死锁现象，就像交通堵塞一样。TCP建立连接后如果发送的数据因为信道质量的原因不能到达目的地，它会不断重发，有可能导致越来越塞，所以需要一个复杂的原理来控制拥塞。而UDP就没有这个烦恼，发出去就不管了。

• 应用场景 很多的实时应用（如IP电话、实时视频会议、某些多人同时在线游戏等）要求源主机以很定的速率发送数据，并且允许在网络发生拥塞时候丢失一些数据，但是要求不能有太大的延时，UDP就刚好适合这种要求。所以说，只有不适合的技术，没有真正没用的技术。