1.运输层的意义
我们知道，IP协议能够把源主机A发送出去的分组按照首部中的目的地址发送到目的主机B，那么，为什么还需要运输层呢？
从IP层来说，通信的两端是两个主机。IP数据报的首部明确的标志了这两个主机的IP地址。但“两个主机之间的通信”这种说法还不够清楚。这是因为，真正进行通信的实体是在主机中的进程，是这个主机中的一个进程和另一个主机中的一个进程在交换数据（即通信）。因此严格的讲，两个主机进行通信的是两个主机中的应用进程互相通信。IP协议虽然能够把分组发送到目的主机，但是这个分组还停留在主机的网络层而没有交付主机中的应用进程。从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。也就是说，端到端的通信是应用进程之间的通信。在一个主机中经常会有很多个应用程序同时分别和另一个主机中的多个应用进程通信。运输层有一个很重要的功能--复用和分用。这里的“复用”是指在发送方不同的应用程序都可以使用同一个运输层协议发送数据，而分用是指接受方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
网络层是为主机之间提供逻辑通信，而运输层是为应用进程之间提供端到端的逻辑通信。运输层还要对收到的报文进行差错检验。在网络层，IP数据包首部中的校验和字段，只检验首部是否出现差错而不检查数据部分。
根据应用程序的不同需求，运输层需要两种不同的运输协议，即面向连接的TCP和无连接的UDP。
为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法对TCP/IP体系的应用进程进行标志。
但是把一个特定机器上运行的特定进程，指明为因特网通信的最后端点还是不可行的。这是因为进程的创建和撤销都是动态的，通信的一方几乎无法识别对方机器的进程。另外，我们往往需要利用目的主机提供的功能来识别终点，而不需要知道具体实现这个功能的进程是哪一个。
解决这个问题的方法就是在运输层使用协议端口号，或者通常简称为端口。这就是说，虽然通信的终点是应用进程，但是我们只要把传送的报文交到目的主机的某一个合适的目的端口，剩下的工作就由TCP来完成。软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。
2.运输层端口号共分为两大类
（1）服务器端使用的端口号 这里又分为两大类，最重要的一类叫做熟知端口号或者系统端口号，数值为0~1023.这些数值可以在网址www.iana.org查到。IANA把这些端口号指派给了TCP/IP最重要的一些应用程序，让所有的用户都知道，当一种新的应用程序出现后，IANA必须为它指派一个熟知端口，否则英特网上的其他应用进程就无法和它进行通信。
另一类叫做登记接口，数值为1024-49151。这类端口号是为没有数值端口号的应用程序使用的，使用这类端口号必须在IANA按照规定的手续登记，以防止重复。
（2）客户端使用的端口号 数值为49152-65535.由于这类端口号仅在客户进程运行时才动态选择，因此又叫做短暂端口号。这类端口号是留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道客户进程使用的端口号，因而可以把数据发送给客户进程。通信结束后，刚才使用的客户端口号已经不复存在了，这个端口号可以供其他客户进程使用。
3.UDP和TCP的区别
3.1UDP特点
（1）UDP是无连接的，即发送数据之前不需要建立连接（当然发送数据结束后也没有连接可释放），因此减少了开销和发送数据之前的时延。
（2）UDP使用最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表
（3）UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就像下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。
（4）UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送率降低。这对某些实时应用很重要。很多的实时应用（如IP电话，实时视频协议）要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太大的时延。UDP正好适用这种要求。但是不使用拥塞控制的UDP有可能引起网络发生非常严重的拥塞问题。
（5）UDP支持一对一、一对多、多对一和多对多的交互通信。
（6）UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。
3.2TCP的特点
（1）TCP是面向连接的运输层协议。这就是说，应用程序在使用TCP协议之前，必须先建立TCP连接，在传送数据完毕后，必须释放已经建立的TCP连接。
（2）每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的（一对一的）
（3）TCP提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达。
（4）TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能够发送数据。TCP连接的两端都设有发送缓存和接收缓存用来临时存放双向通信的数据。
（5）面向字节流。TCP的“流”指的是流入到进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和TCP的交互是一次一个数据块，但TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。
三次握手过程
简单说，三次握手就是让双方都证实对方能发收。
知道对方能收是因为收到对方的因为收到而发的回应。
具体：
1：A发，B收， B知道A能发
2：B发，A收， A知道B能发收
3：A发，B收， B知道A能收
四次挥手过程
TCP连接的释放断开一共需要四步，因此称为“四次挥手”。
因为TCP连接是双向的，因此在四次挥手中，前两次挥手用于断开一个方向的连接，后两次挥手用于断开另一方向的连接。
第一次挥手
若A认为数据发送完成，则它需要向B发送连接释放请求。
该请求只有报文头，头中携带的主要参数为： FIN=1，seq=u。
此时，A将进入FIN-WAIT-1状态。
PS1：FIN=1表示该报文段是一个连接释放请求。
PS2：seq=u，u-1是A向B发送的最后一个字节的序号。
第二次挥手
B收到连接释放请求后，会通知相应的应用程序，告诉它A向B这个方向的连接已经释放。
此时B进入CLOSE-WAIT状态，并向A发送连接释放的应答，其报文头包含： ACK=1，seq=v，ack=u+1。
PS1：ACK=1：除TCP连接请求报文段以外，TCP通信过程中所有数据报的ACK都为1，表示应答。
PS2：seq=v，v-1是B向A发送的最后一个字节的序号。
PS3：ack=u+1表示希望收到从第u+1个字节开始的报文段，并且已经成功接收了前u个字节。
A收到该应答，进入FIN-WAIT-2状态，等待B发送连接释放请求。
第二次挥手完成后，A到B方向的连接已经释放，B不会再接收数据，A也不会再发送数据。
但B到A方向的连接仍然存在，B可以继续向A发送数据。
第三次挥手
当B向A发完所有数据后，向A发送连接释放请求，请求头：FIN=1，ACK=1，seq=w，ack=u+1。
B便进入LAST-ACK状态。
第四次挥手
A收到释放请求后，向B发送确认应答，此时A进入TIME-WAIT状态。
该状态会持续2MSL时间，若该时间段内没有B的重发请求的话，就进入CLOSED状态，撤销TCP。
当B收到确认应答后，也便进入CLOSED状态，撤销TCP。
为什么A要先进入TIME-WAIT状态，等待2MSL时间后才进入CLOSED状态？
为了保证B能收到A的确认应答。
若A发完确认应答后直接进入CLOSED状态，那么如果该应答丢失，B等待超时后就会重新发送连接释放请求，
但此时A已经关闭了，不会作出任何响应，因此B永远无法正常关闭。
2MSL的作用
TIME_WAIT的状态是为了等待连接上所有的分组的消失。单纯的想法，发送端只需要等待一个MSL就足够了。这是不够的，假设现在一个MSL的时候，接收端需要发送一个应答，这时候，我们也必须等待这个应答的消失，这个应答的消失也是需要一个MSL，所以我们需要等待2MSL
扩展（11种状态）
