以下自言自语，提建议感激不尽，挑毛病我就不听
UDP与TCP
UDP是个协议。。。
TCP也是个协议。。。
那么这两个协议之间的区别是什么呢？曾经我被问到这个问题，就开始眉飞色舞地侃侃而谈。“UDP就像是个广播喇叭，遵循UDP的数据报发送后，是无连接的，任何接收端都可以收到；UDP又是不可靠的，为什么？广播喇叭里的话，不是谁都听得见的。TCP是面向连接的，就像是两个人打电话一样，也是可靠的。。。”
今天重温TCP与UDP，虽然理解的还是不怎么透彻，但是相比以前，总算是有了进步，记录下来。
UDP
UDP是传输层协议。传输层协议所需要做的工作很多，但是UDP却做了其中最少的工作。UDP得的要传输的数据以后，仅仅在数据的原有基础上，附加了目的端口号，以及其他两个小字段。然后这个极其简陋的数据报文段就被发出去了。在这个过程中，UDP并没有要求发送方和接收方彼此先认识认识，握个手什么的完全没做，因为这个，UDP被称为是无连接的。
紧接着，根据以上原理，可以记录用UDP的优势：
其一，时间控制精确。怎么精确了？毕竟UDP拿到数据后，就只是给数据加上个端口号，就“嗖”的一下，把数据报文段发出去喽！没耽搁时间啊！对于那种对数据何时发送很看重的主儿，这是至关重要的啊！相比于TCP，省去了握握手、等等人的环节，时间已经很精确了。当然了，是有可能数据没送到，也是有可能数据送到不完整，怕这些你别用啊。。。
其二，无需建立连接。这点就是上面加黑的字体，无连接的。那有什么优势呢？建立连接需要时间，需要资源啊。俩人先认识认识握个手不得需要点时间吗？就算是压马路还对鞋子有磨损呢，何况现在俩人见面都需要喝个咖啡厅什么的，高消费，耗资源啊！
其三，没有连接状态（WTF？都不用建立连接了，自然没有连接状态了）。连接状态需要维护很多号啊、参数什么的，不写了，写了也记不住。由此可见，没有连接状态是很大的优势。
其四，开销小。每个TCP报文段的首部开销为20字节，每个UDP报文段的首部开销为8字节。
TCP
面向连接的运输，TCP。
序号（Seq）和确认号（ACK）。这俩个号在TCP报文段中可是很拽的。为什么他俩这么拽呢，因为没有他俩不行。。。数据是由很多报文段运送的，每个报文段都有自己的序号，并且整体来看，这个序号是递增的且独一无二的。比如第一个报文段序号是0，第二个是1000，第三个是2000。。。没错，是递增，未必是差值为1的等差数列。人之立于世，必循其规。有个序号，大家都按照序号来，公平公正公开，谁也没偏袒，有效避免了争斗，维护了世界和平，看吧，序号就是这么有用，就是这么拽！那确认号呢？确认号是接受端返回给发送端的，这个号代表了序号，就是下一个可以发过来的报文段的序号。比如确认号是2000，那发送端如果是个遵纪守法的好公民，就得发序号是2000的报文段，所以确认号也很拽啊。
A：seq=22，ACK=15，data=‘wtf’——>B；B：seq=15,ACK=22+1=23,data=‘wtf’——>A；A：seq=23，ACK=15+1=16——>B
TCP的连接管理。TCP是个靠谱的讲究人。介绍客户端和服务端相互认识，要让他们首先握手，然后握手，最后握手。握手的时候，怎么也得做点什么吧，第一次握手的时候啊，客户端把提前准备的特殊报文段给服务端。这个特殊报文段里有SYN，所以就被大众称为SYN报文段。SYN报文段除了有SYN，还有客户端随机生成的一个初始序号（client_isn），没错，是序号，很拽的序号。
第二次握手了，服务端拿到了客户端的SYN报文段了，想了半天才反应过来，这得表示表示啊！就也发了一个有SYN的报文段，同时，客户端的SYN报文段里有序号啊！序号！需要确认号呀！服务端就给客户端的序号加一，然后做确认号了，ACK！最后，也带上了一个自己的序号。这个报文段叫做SYNACK报文段。
第三次握手的时候，客户端拿到了服务端的SYNACK报文段，一看这事有门啊，就不客气啦，直接带上了序号和确认号，去建立连接了。
断开连接的过程中，更加体现了TCP的讲究之处，四次告别！足足四次！首先客户端发了个FIN说要断开链接了，然后等服务端消息，这叫FIN_WAIT_1，服务端收到后返回一个ACK说我知道了。这时候，讲究这个特性就提现出来了。客户端这时候不走，人家进入等待，叫做FIN_WAIT_2，收到服务端的FIN后，给服务端返回一个ACK，更讲究的是，这时候了，还不走。客户端进入TIME_WAIT阶段，等个1分钟或者30秒的才缓步离开。
与此同时的服务端，一听说客户端要走，为了不耽误客户端的时间，赶紧接受FIN并且返回ACK，然后服务端也很讲究啊，进入等待阶段，这个阶段叫做CLOSE_WAIT，服务端在这个阶段发送了FIN，等着接受客户端返回的ACK，然后就断开连接了。
最后我就想了啊，这TCP这么讲究干什么啊？难道就是为了讲究才讲究的吗？这个时候，搜索引擎的强大实力显露无遗。
讲究的三次握手原因：谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
来源：知呼，作者：做好自己
讲究的四次挥手是因为TCP有个半关闭状态，假设A.B要释放连接，那么A发送一个释放连接报文给B，B收到后发送确认，这个时候A不发数据，但是B如果发数据A还是要接受，这叫半关闭。然后B还要发给A连接释放报文，然后A发确认，所以是4次。
来源：百度知道，作者：yehua131969
