无论参考OSI还是TCP/IP的网络模型，我们从传输层向更底层看，各层的协议都是在直接或间接的服务于主机与主机之间的通信，而传输层则是在进程与进程通信层面上的。传输层有两个重要的协议——TCP（Transmission ControlProtocol，传输控制协议）和UDP（User Data Protocol，用户数据报协议）。

UDP协议：

UDP(User Datagram Protocol)即用户数据报协议，其传输机制决定了它的最大优点——快，同时也决定了它最大的缺点
——不可靠、不稳定。
　　UDP是无连接的，发送数据之前不需要建立连接(TCP需要)。减少了开销和延时。
　　UDP是面向报文的，对IP数据报只做简单封装(8字节UDP报头)。减少报头开销。
　　UDP没有阻塞机制，宁愿阻塞时丢弃数据不传，也不阻塞造成延时。
　　UDP支持一对一、一对多、多对一、多对多通信。

TCP协议：

TCP(Transmission Control Protocol)传输控制协议，相对于UDP，TCP是面向连接的、提供可靠的数据传输服务。同时也是较UDP开销较大的、传输速度较慢的。
　　TCP提供可靠的、面向连接的数据传输服务。使用TCP通信之前，需要进行“三次握手”建立连接，通信结束后还要使用“四次挥手”断开连接。
　　TCP是点对点的连接。一条TCP连接只能连接两个端点。
　　TCP 提供可靠传输，无差错、不丢失、不重复、按顺序。
　　TCP 提供全双工通信，允许通信双方任何时候都能发送数据，发送方设有发送缓存，接收方设有接收缓存。
　　TCP 面向字节流 。TCP 并不知道所传输的数据的含义，仅把数据看作一连串的字节序列，它也不保证接收方收到的数据块和发送方发出的数据块具有大小对应关系。

在实现了socket服务器端和客户端编程后，我通过查找相关书籍以及网上查找资料后，进一步深入了解了套接字的概念以及socket中TCP的三次握手和四次挥手机制。

一. 套接字（ socket ）概念

网络层的“ip地址”可以唯一标识网络中的主机，而传输层的“端口”可以唯一标识主机中的应用程序（进程）。这样利用二元组（ip地址，端口）就可以标识网络的进程了，网络中的进程通信就可以利用这个标志与其它进程进行交互。使用TCP/IP协议的应用程序通常采用应用编程接口：UNIX BSD的套接字（socket）来实现网络进程之间的通信。就目前而言，几乎所有的应用程序都是采用socket，而现在又是网络时代，网络中进程通信是无处不在，这就是我为什么说“一切皆socket”。 TCP/IP协议族包括运输层、网络层、链路层，而socket所在位置如图，Socket是应用层与TCP/IP协议族通信的中间软件抽象层。

Socket起源于Unix，而Unix/Linux基本哲学之一就是“一切皆文件”。在许多操作系统中，套接字API最初是作为UNIX操作系统的一部分而开发的，所以套接字API与系统的其他I/O设备集成在一起。应用程序要为因特网通信而创建一个套接字（socket）时，操作系统就返回一个小整数作为描述符（descriptor）来标识这个套接字。然后应用程序以该描述符作为传递参数，通过调用相应函数（如read、write、close等）来完成某种操作（如从套接字中读取或写入数据）。

二.TCP/IP协议族

要想理解socket首先得熟悉一下TCP/IP协议族， TCP/IP（Transmission Control Protocol/Internet Protocol）即传输控制协议/网间协议，定义了主机如何连入因特网及数据如何再它们之间传输的标准。
虽然OSI参考模型是国际化标准组织提出了的一个标准，但由于他定义的太过复杂而错过了时间节点，让TCP/IP协议成为了计算机网络通信的事实标准。

从字面意思来看TCP/IP是TCP和IP协议的合称，但实际上TCP/IP协议是指因特网整个TCP/IP协议族。不同于OSI模型的七个分层，TCP/IP协议参考模型把所有的TCP/IP系列协议归类到四个抽象层中。

应用层：TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet 等等
传输层：TCP，UDP
网络层：IP，ICMP，OSPF，EIGRP，IGMP
网络接口层：SLIP，CSLIP，PPP，MTU

因为TCP/IP太过简单，我们也会使用模型化的TCP/IP五层模型来描述计算机网络。

在TCP/IP协议中两个因特网主机通过两个路由器和对应的层连接。各主机上的应用通过一些数据通道相互执行读取操作

三.socket中TCP的三次握手建立连接

在TCP/IP协议中，TCP协议通过三次握手建立一个可靠的连接

第一次握手：客户端尝试连接服务器，向服务器发送syn包（同步序列编号Synchronize Sequence Numbers），syn=j，客户端进入SYN_SEND状态等待服务器确认。
第二次握手：服务器接收客户端syn包并确认（ack=j+1），同时向客户端发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态。
第三次握手：第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

TCP连接至此建立起来了。为什么要做三次握手呢？握手的过程实际上是在通知对方自己的初始化序号(Initial SequenceNumber)，简称ISN，也就是上图中的x和y。x和y会被当作之后传输数据的一个依据，以保证TCP报文在传输过程中不会混乱。
　　我们回到TCP Header结构来看，Sequence Number和Acknowledgment Number都是占32位，所以seq和ack的取值范围是0 ～ 2^32 -1。
seq和ack每增加到2^32-1，则重新从0开始。值得一提的是，seq的初始值(ISN)并不是每次都从0开始的。我们设想一下，如果是从0开始，那么当TCP三次握手建立连接完成后，Client发送了30个报文，然后Client断线了。于是Client重连，再次用0作为初始的seq，这样就会出现两个报文具有相同的seq，就出现了混乱。
事实上TCP的做法是每隔4微秒就对ISN做一次加1操作，当ISN到达2^32-1后再次从0开始的时候，已经过去了几个小时，之前的seq=0的报文已经不存在于这次连接中了，这样就避免了上面的问题。

定睛一看，服务器socket与客户端socket建立连接的部分其实就是大名鼎鼎的三次握手
但是这个三次握手发生在socket的那几个函数中呢？请看下图：

从图中可以看出：当客户端调用connect时，触发了连接请求，向服务器发送了SYN J包，这时connect进入阻塞状态；服务器监听到连接请求，即收到SYN J包，调用accept函 数接收请求向客户端发送SYN K ，ACK J+1，这时accept进入阻塞状态；客户端收到服务器的SYN K ，ACK J+1之后，这时connect返回，并对SYN K进行确认；服务器收到ACK K+1时，accept返回，至此三次握手完毕，连接建立。

总结：客户端的connect在三次握手的第二个次返回，而服务器端的accept在三次握手的第三次返回。

四.socket中TCP的四次挥手断开连接

图示过程如下：

　(1)Client向Server发送断开连接请求的报文段，seq=m(m为Client最后一次向Server发送报文段的最后一个字节序号加1)，Client进入FIN-WAIT-1状态。
　　(2)Server收到断开报文段后，向Client发送确认报文段，seq=n(n为Server最后一次向Client发送报文段的最后一个字节序号加1)，ack=m+1，Server进入CLOSE-WAIT状态。此时这个TCP连接处于半开半闭状态，Server发送数据的话，Client仍然可以接收到。
　　(3)Server向Client发送断开确认报文段，seq=u(u为半开半闭状态下Server最后一次向Client发送报文段的最后一个字节序号加1)，ack=m+1，Server进入LAST-ACK状态。
　　(4)Client收到Server的断开确认报文段后，向Server发送确认断开报文，seq=m+1，ack=u+1，Client进入TIME-WAIT状态。
　　(5)Server收到Client的确认断开报文，进入CLOSED状态，断开了TCP连接。
　　(6)Client在TIME-WAIT状态等待一段时间(时间为2*MSL((Maximum Segment Life))，确认Client向Server发送的最后一次断开确认到达(如果没有到达，Server会重发步骤(3)中的断开确认报文段给Client，告诉Client你的最后一次确认断开没有收到)。如果Client在TIME-WAIT过程中没有再次收到Server的报文段，就进入CLOSES状态。TCP连接至此断开。

TCP连接可靠性的体现：

(1)TCP报文段的长度可变，根据收发双方的缓存状态、网络状态而调整。
　　(2)当TCP收到发自TCP连接另一端的数据，它将发送一个确认。
　　(3)当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段，如果不能及时收到一个确认，将重发这个报文段。
　　(4)TCP将保持它首部和数据的检验和。如果通过检验和发现报文段有差错，这个报文段将被丢弃，等待超时重传。
　　(5)TCP将数据按字节排序，报文段中有序号，以确保顺序的正确性。
　　(6)TCP还能提供流量控制。TCP连接的每一方都有收发缓存。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。
　　需要注意的是，TCP报文传输采用接受后返回确认的方式来保证报文传输的可靠性，并不是意味着发送方在发送一个报文段后就进入等待确认状态，让后面的报文段等着。也不是接收方在接收到一个报文后，对每一个报文都进行回复确认。
　　真实的情况是，对于发送方，在发送一个报文段后，复制一份该报文段的副本，然后继续进行下一个报文段的发送，如果没有得到发送方的回复确认，就对该报文段进行超时重发。对于接收方来说，则采用“积累确认”的方式进行回复。接收者收到多个连续的报文段后，只回复确认最后一个报文段，表示在这之前的数据都已收到。以此达到提升传输效率的目的。

TCP流量控制：

由于接收方缓存的限制，发送窗口不能大于接收方接收窗口。在报文段首部有一个字段就叫做窗口(rwnd)，这便是用于告诉对方自己的接收窗口，可见窗口的大小是可以变化的，这个叫做滑动窗口协议。　
　　

总结起来如上图，TCP的流量和阻塞控制采用“慢启动”、“加性增”、“乘性减”的策略。
　　慢启动：初始的窗口值很小，但是按指数规律渐渐增长，直到达到慢开始门限(ssthresh)。
　　加性增：窗口值达到慢开始门限后，每发送一个报文段，窗口值增加一个单位量。
　　乘性减：无论什么阶段，只要出现超时，则把窗口值减小一半。