一、网络编程概述

1.1 网络概述

网络编程技术是当前一种主流的编程技术，随着联网趋势的逐步增强以及网络应用程序的大量出现，所以在实际的开发中网络编程技术获得了大量的使用。本章中以浅显的基础知识说明和实际的案例使广大初学者能够进入网络编程技术的大门，至于以后的实际修行就要阅读进阶的书籍以及进行大量的实际练习。

1.2 客户端网络编程步骤

客户端(Client)是指网络编程中首先发起连接的程序，客户端一般实现程序界面和基本逻辑实现，在进行实际的客户端编程时，无论客户端复杂还是简单，以及客户端实现的方式，客户端的编程主要由三个步骤实现：

（1）建立网络连接

客户端网络编程的第一步都是建立网络连接。在建立网络连接时需要指定连接到的服务器的IP地址和端口号，建立完成以后，会形成一条虚拟的连接，后续的操作就可以通过该连接实现数据交换了。

（2）交换数据

连接建立以后，就可以通过这个连接交换数据了。交换数据严格按照请求响应模型进行，由客户端发送一个请求数据到服务器，服务器反馈一个响应数据给客户端，如果客户端不发送请求则服务器端就不响应。

根据逻辑需要，可以多次交换数据，但是还是必须遵循请求响应模型。

（3）关闭网络连接

在数据交换完成以后，关闭网络连接，释放程序占用的端口、内存等系统资源，结束网络编程。

最基本的步骤一般都是这三个步骤，在实际实现时，步骤2会出现重复，在进行代码组织时，由于网络编程是比较耗时的操作，所以一般开启专门的现场进行网络通讯。

1.3 服务器端网络编程步骤

服务器端(Server)是指在网络编程中被动等待连接的程序，服务器端一般实现程序的核心逻辑以及数据存储等核心功能。服务器端的编程步骤和客户端不同，是由四个步骤实现，依次是：

（1）监听端口

服务器端属于被动等待连接，所以服务器端启动以后，不需要发起连接，而只需要监听本地计算机的某个固定端口即可。

这个端口就是服务器端开放给客户端的端口，服务器端程序运行的本地计算机的IP地址就是服务器端程序的IP地址。

（2）获得连接

当客户端连接到服务器端时，服务器端就可以获得一个连接，这个连接包含客户端的信息，例如客户端IP地址等等，服务器端和客户端也通过该连接进行数据交换。

一般在服务器端编程中，当获得连接时，需要开启专门的线程处理该连接，每个连接都由独立的线程实现。

（3）交换数据

服务器端通过获得的连接进行数据交换。服务器端的数据交换步骤是首先接收客户端发送过来的数据，然后进行逻辑处理，再把处理以后的结果数据发送给客户端。简单来说，就是先接收再发送，这个和客户端的数据交换数序不同。

其实，服务器端获得的连接和客户端连接是一样的，只是数据交换的步骤不同。

当然，服务器端的数据交换也是可以多次进行的。

在数据交换完成以后，关闭和客户端的连接。

（4）关闭连接

当服务器程序关闭时，需要关闭服务器端，通过关闭服务器端使得服务器监听的端口以及占用的内存可以释放出来，实现了连接的关闭。

其实服务器端编程的模型和呼叫中心的实现是类似的，例如移动的客服电话10086就是典型的呼叫中心，当一个用户拨打10086时，转接给一个专门的客服人员，由该客服实现和该用户的问题解决，当另外一个用户拨打10086时，则转接给另一个客服，实现问题解决，依次类推。

在服务器端编程时，10086这个电话号码就类似于服务器端的端口号码，每个用户就相当于一个客户端程序，每个客服人员就相当于服务器端启动的专门和客户端连接的线程，每个线程都是独立进行交互的。

这就是服务器端编程的模型，只是TCP方式是需要建立连接的，对于服务器端的压力比较大，而UDP是不需要建立连接的，对于服务器端的压力比较小罢了。

二、TCP详解

互联网协议族（英语：Internet Protocol Suite，缩写为IPS），是一个网络通信模型，以及一整个网络传输协议家族，为互联网的基础通信架构。它常被通称为TCP/IP协议族（英语：TCP/IP Protocol Suite，或TCP/IP Protocols），简称TCP/IP协议。因为这个协议家族的两个核心协议，包括TCP（传输控制协议）和IP（网际协议），为这个家族中最早通过的标准。

对于应用层开发人员，接触最多的网络协议通常都是传输层的TCP，为什么这么说，因为再往上的应用层协议，如：HTTP、HTTPS、POP3、SMTP、RPC、FTP、TELNET等等都是基于TCP传输层协议。但对于IP协议，对于应用程序员来说更多的印象还是IP地址这个东西，实际上IP协议是位于TCP协议之下的网络层，对于应用层程序员来说很难直接接触。

2.1 TCP编程的服务器端一般步骤是

（1）创建一个socket，用函数socket()； 

（2）设置socket属性，用函数setsockopt(); * 可选 

（3）绑定IP地址、端口等信息到socket上，用函数bind(); 

（4）开启监听，用函数listen()； 

（5）接收客户端上来的连接，用函数accept()； 

（6）收发数据，用函数send()和recv()，或者read()和write(); 

（7）关闭网络连接；

（8）关闭监听；

2.2 TCP编程的客户端一般步骤是

（1）创建一个socket，用函数socket()； 

（2）设置socket属性，用函数setsockopt();* 可选 

（3）绑定IP地址、端口等信息到socket上，用函数bind();* 可选 

（4）设置要连接的对方的IP地址和端口等属性； 

（5）连接服务器，用函数connect()； 

（6）收发数据，用函数send()和recv()，或者read()和write(); 

（7）关闭网络连接；

2.3 TCP补充

TCP充分实现了数据传输时各种控制功能，可以进行丢包的重发控制，还可以对次序乱掉的分包进行顺序控制。而这些在UDP中都没有。此外，TCP作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。

2.4 TCP的状态转换图：

2.5 三次握手

（1）第一次握手：客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；

（2）第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

（3）第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

2,6为什么会采用三次握手，若采用二次握手可以吗？四次呢？

建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。

采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。

失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。

采用两次握手不行，原因就是上面说的失效的连接请求的特殊情况。而在三次握手中，client和server都有一个发syn和收ack的过程， 双方都是发后能收， 表明通信则准备工作OK。

为什么不是四次握手呢？大家应该知道通信中著名的蓝军红军约定，这个例子说明，通信不可能100%可靠， 而上面的三次握手已经做好了通信的准备工作， 再增加握手， 并不能显著提高可靠性， 而且也没有必要。

2.7 四次挥手

数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，假设客户端主动关闭，服务器被动关闭。

（1）第一次挥手：客户端发送一个FIN，用来关闭客户端到服务器的数据传送，也就是客户端告诉服务器：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，客户端依然会重发这些数据)，但是，此时客户端还可 以接受数据。

FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

（2）第二次挥手：服务器收到FIN包后，发送一个ACK给对方并且带上自己的序列号seq，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

（3）第三次挥手：服务器发送一个FIN，用来关闭服务器到客户端的数据传送，也就是告诉客户端，我的数据也发送完了，不会再给你发数据了。由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

（4）第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。至此，完成四次挥手。

2.8 为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

（1）第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

（2）第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

2.9 为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候，服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。

而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

2.10 TCP粘包和拆包产生的原因

（1）应用程序写入数据的字节大小大于套接字发送缓冲区的大小

（2）进行MSS大小的TCP分段。MSS是最大报文段长度的缩写。MSS是TCP报文段中的数据字段的最大长度。数据字段加上TCP首部才等于整个的TCP报文段。所以MSS并不是TCP报文段的最大长度，而是：MSS=TCP报文段长度-TCP首部长度

（3）以太网的payload大于MTU进行IP分片。MTU指：一种通信协议的某一层上面所能通过的最大数据包大小。如果IP层有一个数据包要传，而且数据的长度比链路层的MTU大，那么IP层就会进行分片，把数据包分成托干片，让每一片都不超过MTU。注意，IP分片可以发生在原始发送端主机上，也可以发生在中间路由器上。

2.11 TCP粘包和拆包的解决策略

（1）消息定长。例如100字节。

（2）在包尾部增加回车或者空格符等特殊字符进行分割，典型的如FTP协议

（3）将消息分为消息头和消息尾。

（4）其它复杂的协议，如RTMP协议等。

2.12 TCP的四种定时器

TCP中有四种计时器（Timer），分别为：

（1）重传计时器：Retransmission Timer

（2）坚持计时器：Persistent Timer

（3）保活计时器：Keeplive Timer

（4）时间等待计时器：Timer_Wait Timer

1、重传计时器

大家都知道TCP是保证数据可靠传输的。怎么保证呢？带确认的重传机制。在滑动窗口协议中，接受窗口会在连续收到的包序列中的最后一个包向接收端发送一个ACK，当网络拥堵的时候，发送端的数据包和接收端的ACK包都有可能丢失。

TCP为了保证数据可靠传输，就规定在重传的“时间片”到了以后，如果还没有收到对方的ACK，就重发此包，以避免陷入无限等待中。

当TCP发送报文段时，就创建该特定报文的重传计时器。可能发生两种情况：

1）若在计时器截止时间到之前收到了对此特定报文段的确认，则撤销此计时器。

2）若在收到了对此特定报文段的确认之前计时器截止时间到，则重传此报文段，并将计时器复位。

2、坚持计时器

专门对付零窗口通知而设立的

先来考虑一下情景：发送端向接收端发送数据包知道接受窗口填满了，然后接受窗口告诉发送方接受窗口填满了停止发送数据。此时的状态称为“零窗口”状态，发送端和接收端窗口大小均为0.直到接受TCP发送确认并宣布一个非零的窗口大小。但这个确认会丢失。

我们知道TCP中，对确认是不需要发送确认的。若确认丢失了，接受TCP并不知道，而是会认为他已经完成了任务，并等待着发送TCP接着会发送更多的报文段。

但发送TCP由于没有收到确认，就等待对方发送确认来通知窗口大小。双方的TCP都在永远的等待着对方。

要打开这种死锁，TCP为每一个链接使用一个持久计时器。当发送TCP收到窗口大小为0的确认时，就坚持启动计时器。当坚持计时器期限到时，发送TCP就发送一个特殊的报文段，叫做探测报文。

这个报文段只有一个字节的数据。他有一个序号，但他的序号永远不需要确认；甚至在计算机对其他部分的数据的确认时该序号也被忽略。探测报文段提醒接受TCP：确认已丢失，必须重传。

坚持计时器的值设置为重传时间的数值。但是，若没有收到从接收端来的响应，则需发送另一个探测报文段，并将坚持计时器的值加倍和复位。

发送端继续发送探测报文段，将坚持计时器设定的值加倍和复位，直到这个值增大到门限值（通常是60秒）为止。在这以后，发送端每个60秒就发送一个探测报文，直到窗口重新打开。

3、保活计时器

保活计时器使用在某些实现中，用来防止在两个TCP之间的连接出现长时间的空闲。假定客户打开了到服务器的连接，传送了一些数据，然后就保持静默了。也许这个客户出故障了。在这种情况下，这个连接将永远的处理打开状态。

要解决这种问题，在大多数的实现中都是使服务器设置保活计时器。每当服务器收到客户的信息，就将计时器复位。通常设置为两小时。

若服务器过了两小时还没有收到客户的信息，他就发送探测报文段。若发送了10个探测报文段（每一个像个75秒）还没有响应，就假定客户除了故障，因而就终止了该连接。

这种连接的断开当然不会使用四次握手，而是直接硬性的中断和客户端的TCP连接。

4、时间等待计时器

时间等待计时器是在四次握手的时候使用的。四次握手的简单过程是这样的：假设客户端准备中断连接，首先向服务器端发送一个FIN的请求关闭包（FIN=final），然后由established过渡到FIN-WAIT1状态。

服务器收到FIN包以后会发送一个ACK，然后自己有established进入CLOSE-WAIT.此时通信进入半双工状态，即留给服务器一个机会将剩余数据传递给客户端，传递完后服务器发送一个FIN+ACK的包，表示我已经发送完数据可以断开连接了，就这便进入LAST_ACK阶段。

客户端收到以后，发送一个ACK表示收到并同意请求，接着由FIN-WAIT2进入TIME-WAIT阶段。服务器收到ACK，结束连接。

此时（即客户端发送完ACK包之后），客户端还要等待2MSL（MSL=maxinum segment lifetime最长报文生存时间，2MSL就是两倍的MSL）才能真正的关闭连接。

三、UDP详解

2.1 UDP是什么

UDP(User Datagram Protocol)，中文意思是用户数据报协议，方式类似于发短信息，是一种物美价廉的通讯方式，使用该种方式无需建立专用的虚拟连接，由于无需建立专用的连接，所以对于服务器的压力要比TCP小很多，所以也是一种常见的网络编程方式。但是使用该种方式最大的不足是传输不可靠，当然也不是说经常丢失，就像大家发短信息一样，理论上存在收不到的可能，这种可能性可能是1%，反正比较小，但是由于这种可能的存在，所以平时我们都觉得重要的事情还是打个电话吧(类似TCP方式)，一般的事情才发短信息(类似UDP方式)。网络编程中也是这样，必须要求可靠传输的信息一般使用TCP方式实现，一般的数据才使用UDP方式实现。

UDP方式的网络编程也在Java语言中获得了良好的支持，由于其在传输数据的过程中不需要建立专用的连接等特点，所以在Java API中设计的实现结构和TCP方式不太一样。当然，需要使用的类还是包含在java.net包中。

2.2 UDP主要实现

DatagramSocket:

DatagramSocket类实现“网络连接”，包括客户端网络连接和服务器端网络连接。虽然UDP方式的网络通讯不需要建立专用的网络连接，但是毕竟还是需要发送和接收数据，DatagramSocket实现的就是发送数据时的发射器，以及接收数据时的监听器的角色。类比于TCP中的网络连接，该类既可以用于实现客户端连接，也可以用于实现服务器端连接。

DatagramPacket:

DatagramPacket类实现对于网络中传输的数据封装，也就是说，该类的对象代表网络中交换的数据。在UDP方式的网络编程中，无论是需要发送的数据还是需要接收的数据，都必须被处理成DatagramPacket类型的对象，该对象中包含发送到的地址、发送到的端口号以及发送的内容等。其实DatagramPacket类的作用类似于现实中的信件，在信件中包含信件发送到的地址以及接收人，还有发送的内容等，邮局只需要按照地址传递即可。在接收数据时，接收到的数据也必须被处理成DatagramPacket类型的对象，在该对象中包含发送方的地址、端口号等信息，也包含数据的内容。和TCP方式的网络传输相比，IO编程在UDP方式的网络编程中变得不是必须的内容，结构也要比TCP方式的网络编程简单一些。

2.3 UDP应用场景

（1）面向数据报方式

（2）网络数据大多为短消息?

（3）拥有大量Client

（4）对数据安全性无特殊要求

（5）网络负担非常重，但对响应速度要求高

2.4 UDP编程的服务器端一般步骤是

（1）创建一个socket，用函数socket()；

（2）设置socket属性，用函数setsockopt();* 可选

（3）绑定IP地址、端口等信息到socket上，用函数bind();

（4）循环接收数据，用函数recvfrom();

（5）关闭网络连接；

2.5UDP编程的客户端一般步骤

（1）创建一个socket，用函数socket()；

（2）设置socket属性，用函数setsockopt();* 可选

（3）绑定IP地址、端口等信息到socket上，用函数bind();* 可选

（4）设置对方的IP地址和端口等属性;

（5）发送数据，用函数sendto();

（6）关闭网络连接；

2.6 UDP补充

UDP不提供复杂的控制机制，利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻，立刻按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况下，UDP也无法进行流量控制等避免网络拥塞的行为。此外，传输途中如果出现了丢包，UDO也不负责重发。甚至当出现包的到达顺序乱掉时也没有纠正的功能。如果需要这些细节控制，那么不得不交给由采用UDO的应用程序去处理。换句话说，UDP将部分控制转移到应用程序去处理，自己却只提供作为传输层协议的最基本功能。UDP有点类似于用户说什么听什么的机制，但是需要用户充分考虑好上层协议类型并制作相应的应用程序。

四、TCP和UDP的区别

4.1 TCP与UDP基本区别

（1）TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接（2）TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保   证可靠交付（3）TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

（4）每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信（5）TCP首部开销20字节;UDP的首部开销小，只有8个字节（6）TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

4.2具体编程时的区别

（1）socket()的参数不同?

（2）UDP Server不需要调用listen和accept?

（3）UDP收发数据用sendto/recvfrom函数?

（4）TCP：地址信息在connect/accept时确定?

（5）UDP：在sendto/recvfrom函数中每次均 需指定地址信息?

（6）UDP：shutdown函数无效