1 网络模型
网络编程的本质是两个设备之间的数据交换，当然，在计算机网络中，设备主要指计算机。数据传递本身没有多大的难度，不就是把一个设备中的数据发送给两外一个设备，然后接受另外一个设备反馈的数据。
现在的网络编程基本上都是基于请求/响应方式的，也就是一个设备发送请求数据给另外一个，然后接收另一个设备的反馈。
在网络编程中，发起连接程序，也就是发送第一次请求的程序，被称作客户端(Client)，等待其他程序连接的程序被称作服务器(Server)。客户端程序可以在需要的时候启动，而服务器为了能够时刻相应连接，则需要一直启动。例如以打电话为例，首先拨号的人类似于客户端，接听电话的人必须保持电话畅通类似于服务器。
连接一旦建立以后，就客户端和服务器端就可以进行数据传递了，而且两者的身份是等价的。
在一些程序中，程序既有客户端功能也有服务器端功能，最常见的软件就是BT、emule这类软件了。
1.1 IP地址与域名
在现实生活中，如果要打电话则需要知道对应人的电话号码，如果要寄信则需要知道收信人的地址。在网络中也是这样，需要知道一个设备的位置，则需要使用该设备的IP地址，具体的连接过程由硬件实现，程序员不需要过多的关心。
IP地址是一个规定，现在使用的是IPv4，既由4个0-255之间的数字组成，在计算机内部存储时只需要4个字节即可。在计算机中，IP地址是分配给网卡的，每个网卡有一个唯一的IP地址，如果一个计算机有多个网卡，则该台计算机则拥有多个不同的IP地址，在同一个网络内部，IP地址不能相同。IP地址的概念类似于电话号码、身份证这样的概念。
由于IP地址不方便记忆，所以有专门创造了域名(Domain Name)的概念，其实就是给IP取一个字符的名字，例如163.com、sina.com等。IP和域名之间存在一定的对应关系。如果把IP地址类比成身份证号的话，那么域名就是你的姓名。
其实在网络中只能使用IP地址进行数据传输，所以在传输以前，需要把域名转换为IP，这个由称作DNS的服务器专门来完成。
所以在网络编程中，可以使用IP或域名来标识网络上的一台设备。
1.2 端口的概念
为了在一台设备上可以运行多个程序，人为的设计了端口(Port)的概念，类似的例子是公司内部的分机号码。
规定一个设备有216个，也就是65536个端口，每个端口对应一个唯一的程序。每个网络程序，无论是客户端还是服务器端，都对应一个或多个特定的端口号。由于0-1024之间多被操作系统占用，所以实际编程时一般采用1024以后的端口号。
使用端口号，可以找到一台设备上唯一的一个程序。所以如果需要和某台计算机建立连接的话，只需要知道IP地址或域名即可，但是如果想和该台计算机上的某个程序交换数据的话，还必须知道该程序使用的端口号。
1.3 网络模型图
2 Socket入门
2.1 什么是Socket
Socket就是为网络服务提供的一种机制
通讯双方都有Socket
网络通讯就是Socket间的通讯
数据在两个Socket间通过IO传输
跨语言传输（二进制+IP+PORT）
核心TCP和UDP
2.2 TCP和UDP区别
UDP:
a、面向无连接，将数据及源封装在数据包中，不需要建立连接
b、每个数据报的大小限制在64K内
c、因无连接，是不可靠协议
d、不需要连接连接，速度快
TCP：
a、建立连接，形成传输数据的通道
b、在连接中进行大数据量传输，以字节流的形式
c、通过三次握手完成连接，是可靠协议
d、必须建立连接，效率会稍低
TCP和UDP协议不互通哟！！！！！
2.3 UDP协议样例
-
//udp服务端 -
public class UDPServer { -
public static void main(String[] args) throws IOException { -
//1.ip端口+端口号 -
System.out.println("udp服务已经启动...8080"); -
//创建服务器端口号 默认使用本机ip -
DatagramSocket ds=new DatagramSocket(8080); -
//服务器接收客户端1024个字节 -
byte[] bytes=new byte[1024]; -
//定义数据包 -
DatagramPacket dp = new DatagramPacket(bytes, bytes.length); -
//接受客户端求，将数据封装给数据包，如果客户端不忘服务器发送请求，就一直阻塞 -
ds.receive(dp); -
System.out.println("来源ip："+dp.getAddress()+",端口号:"+dp.getPort()); -
String result=new String(dp.getData(),0,dp.getLength()); -
System.out.println(result); -
ds.close(); -
} -
} -
//客户端 -
public class UDPClient { -
public static void main(String[] args) throws IOException { -
System.out.println("udp客户端启动连接。。。"); -
//不传入端口号， 则表示作为客户端 -
DatagramSocket ds = new DatagramSocket(); -
String str="Hello，我是客户端"; -
byte[] bytes=str.getBytes(); -
DatagramPacket dp = new DatagramPacket(bytes, bytes.length, InetAddress.getByName("127.0.0.1"), 8080); -
ds.send(dp); -
ds.close(); -
} -
}
2.4 TCP
2.4.1 TCP报文格式
一般需要了解一下几个字段：
（1）序号：Seq序号，占32位，用来表示从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标识
（2）确认序号：ACK序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ACK=Seq+1
（2）标志位共六个：URG、ACK、PSH、RST、SYN、FIN含义：
（a）URG：紧急指针
（b）ACK:确认序号有效
（c）PSH:接收方应该尽快将这个报文交给应用层
（d）RST:充值连接
（e）SYN:发起一个新连接
（f）FIN:释放一个连接
需要注意的是：
（A）不要将确认序号Ack与标志位中的ACK搞混了。
（B）确认方Ack=发起方Req+1，两端配对
2.4.2 TCP三次握手
所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：
第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SEND状态，等待Server确认。
第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ACK=J+1，随机产生一个seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RECV状态。
第三次握手：Client收到确认后，检查ACK是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ACK=K+1，并将数据包发送给Server，Server检查ACK是否为K+1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间就可以开始传输数据了。
SYN攻击：在三次握手过程中，Server发送SYN-ACK后，收到Client的ACK之前的TCP连接称为半连接，此时Serve处于SYN_RECV状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断的发送SYN包，Server回复确认包，并等待Client的确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络阻塞甚至系统瘫痪。SYN攻击就是一种典型的DDOS攻击，检测SYN攻击方式也很简单，即当有大量半连接状态且源地址是随机的，则可以断定遭到SYN攻击了，使用如下命令让其无处可逃：netstat -nap|grep SYN_RECV
2.4.3 四次挥手
所谓四次挥手即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总发送三个包以确认连接的断开。在Socket编程中，这一过程由客户端或服务端任一方执行close来触发，流程如下：
由于TCP连接是全双工的，因此每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。
（1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传输，Client进入FIN_WAIT_1状态。
（2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态
（3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传输，Server进入LAST_ACK状态
（4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手
2.4.4 三次握手和四次挥手面试问题
（1）为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
这是因为Server在LISTEN状态下，当收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不在发送数据了但是还能接受数据，己方也未必全部数据都发送给对方，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方表示同意现在关闭连接，因此己方ACK和FIN一般都会分开发送。
（2）为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
这是因为虽然双方都同意关闭连接了，而且握手的四个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISHED状态那样），但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_WAIT状态下的Socket可能会因为超时未收到ACK报文而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
2.4.5TCP的滑动窗口机制
TCP这个协议是网络中使用的比较广泛，他是一个面向连接的可靠的传输协议。既然是一个可靠的传输协议就需要对数据进行确认。TCP协议里窗口机制有2种：一种是固定的窗口大小；一种是滑动的窗口。这个窗口大小就是我们一次传输几个数据。对所有数据帧按顺序赋予编号，发送方在发送过程中始终保持着一个发送窗口，只有落在发送窗口内的帧才允许被发送；同时接收方也维持着一个接收窗口，只有落在接收窗口内的帧才允许接收。这样通过调整发送方窗口和接收方窗口的大小可以实现流量控制。
TCP滑动窗口技术通过动态改变窗口大小来调节两台主机间数据传输。每个TCP/IP主机支持全双工数据传输，因此TCP有两个滑动窗口：一个用于接收数据，另一个用于发送数据。TCP使用肯定确认技术，其确认号指的是下一个所期待的字节。 假定发送方设备以每一次三个数据包的方式发送数据，也就是说，窗口大小为3。发送方发送序列号为1、2、3的三个数据包，接收方设备成功接收数据包，用序列号4确认。发送方设备收到确认，继续以窗口大小3发送数据。当接收方设备要求降低或者增大网络流量时，可以对窗口大小进行减小或者增加，本例降低窗口大小为2，每一次发送两个数据包。当接收方设备要求窗口大小为0，表明接收方已经接收了全部数据，或者接收方应用程序没有时间读取数据，要求暂停发送。发送方接收到携带窗口号为0的确认，停止这一方向的数据传输。
我们可以看下面一张图来分析一下固定窗口大小有什么问题。
这里我们可以看到假设窗口的大小是1，也是就每次只能发送一个数据只有接受方对这个数据进行确认了以后才能发送第2个数据。我们可以看到发送方每发送一个数据接受方就要给发送方一个ACK对这个数据进行确认。只有接受到了这个确认数据以后发送方才能传输下个数据。 这样我们考虑一下如果说窗口过小，那么当传输比较大的数据的时候需要不停的对数据进行确认，这个时候就会造成很大的延迟。如果说窗口的大小定义的过大。我们假设发送方一次发送100个数据。但是接收方只能处理50个数据。这样每次都会只对这50个数据进行确认。发送方下一次还是发送100个数据，但是接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。所以我们就引入了滑动窗口机制，窗口的大小并不是固定的而是根据我们之间的链路的带宽的大小，这个时候链路是否拥护塞。接受方是否能处理这么多数据了。
我们看看滑动窗口是如何工作的。我们看下面几张图。
首先是第一次发送数据这个时候的窗口大小是根据链路带宽的大小来决定的。我们假设这个时候窗口的大小是3。这个时候接受方收到数据以后会对数据进行确认告诉发送方我下次希望手到的是数据是多少。这里我们看到接收方发送的ACK=3(这是发送方发送序列2的回答确认，下一次接收方期望接收到的是3序列信号)。这个时候发送方收到这个数据以后就知道我第一次发送的3个数据对方只收到了2个。就知道第3个数据对方没有收到。下次在发送的时候就从第3个数据开始发。这个时候窗口大小就变成了2 。
这个时候发送方发送2个数据。
看到接收方发送的ACK是5就表示他下一次希望收到的数据是5，发送方就知道我刚才发送的2个数据对方收了这个时候开始发送第5个数据。
这就是滑动窗口的工作机制，当链路变好了或者变差了这个窗口还会发生变话，并不是第一次协商好了以后就永远不变了。
滑动窗口协议
滑动窗口协议，是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。
只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。
收发两端的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。
当发送窗口和接收窗口的大小都等于1时，就是停止等待协议。
2.4.6 流量控制
流量控制方面主要有两个要点需要掌握。一是TCP利用滑动窗口实现流量控制的机制；二是如何考虑流量控制中的传输效率。
1. 流量控制
所谓流量控制，主要是接收方传递信息给发送方，使其不要发送数据太快，是一种端到端的控制。主要的方式就是返回的ACK中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送：
这里面涉及到一种情况，如果B已经告诉A自己的缓冲区已满，于是A停止发送数据；等待一段时间后，B的缓冲区出现了富余，于是给A发送报文告诉A我的rwnd大小为400，但是这个报文不幸丢失了，于是就出现A等待B的通知而且B等待A发送数据的死锁状态。为了处理这种问题，TCP引入了持续计时器（Persistence timer），当A收到对方的零窗口通知时，就启用该计时器，时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，如果结果仍然等于0，则重设持续计时器，继续等待。
2. 传递效率
一个显而易见的问题是：单个发送字节单个确认，和窗口有一个空余即通知发送方发送一个字节，无疑增加了网络中的许多不必要的报文（请想想为了一个字节数据而添加的40字节头部吧！），所以我们的原则是尽可能一次多发送几个字节，或者窗口空余较多的时候通知发送方一次发送多个字节。对于前者我们广泛使用Nagle算法，即：
*1. 若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的字节先缓存起来；
*2. 当发送方收到第一个字节的确认后（也得到了网络情况和对方的接收窗口大小），再把缓冲区的剩余字节组成合适大小的报文发送出去；
*3. 当到达的数据已达到发送窗口大小的一半或以达到报文段的最大长度时，就立即发送一个报文段；
对于后者我们往往的做法是让接收方等待一段时间，或者接收方获得足够的空间容纳一个报文段或者等到接受缓存有一半空闲的时候，再通知发送方发送数据。
2.4.7 拥塞控制
网络中的链路容量和交换结点中的缓存和处理机都有着工作的极限，当网络的需求超过它们的工作极限时，就出现了拥塞。拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。常用的方法就是：
1. 慢开始、拥塞控制
2. 快重传、快恢复
一切的基础还是慢开始，这种方法的思路是这样的：
-1. 发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口；
-2. 当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文；
-3. 当收到第一个字节的数据的确认后，就发送2个字节的报文；
-4. 若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级；
-5. 最后会达到一个提前预设的“慢开始门限”，比如24，即一次发送了24个分组，此时遵循下面的条件判定：
*1. cwnd < ssthresh， 继续使用慢开始算法；
*2. cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法；
*3. cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法；
-6. 所谓拥塞避免算法就是：每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长；
-7. 当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法（较低的起点，指数级增长）；
上述方法的目的是在拥塞发生时循序减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。慢开始和拥塞控制算法常常作为一个整体使用，而快重传和快恢复则是为了减少因为拥塞导致的数据包丢失带来的重传时间，从而避免传递无用的数据到网络。
快重传的机制是：
-1. 接收方建立这样的机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求；
-2. 一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立刻重传该包；
-3. 此时发送方开始执行“快恢复”算法：
*1. 慢开始门限减半；
*2. cwnd设为慢开始门限减半后的数值；
*3. 执行拥塞避免算法（高起点，线性增长）；
2.4.8 TCP滑动窗口和socket缓冲区之间的关系
（1）TCP的滑动窗口大小实际上就是socket的接收缓冲区大小的字节数
（2）对于server端的socket一定要在listen之前设置缓冲区大小，因为，accept时新产生的socket会继承监听socket的缓冲区大小。对于client端的socket一定要在connet之前设置缓冲区大小，因为connet时需要进行三次握手过程，会通知对方自己的窗口大小。在connet之后再设置缓冲区，已经没有什么意义。
（3）由于缓冲区大小在TCP头部只有16位来表示，所以它的最大值是65536，但是对于一些情况来说需要使用更大的滑动窗口，这时候就要使用扩展的滑动窗口，如光纤高速通信网络，或者是卫星长连接网络，需要窗口尽可能的大。这时会使用扩展的32位的滑动窗口大小。
2.4.9、滑动窗口移动规则：
1、窗口合拢：在收到对端数据后，自己确认了数据的正确性，这些数据会被存储到缓冲区，等待应用程序获取。但这时候因为已经确认了数据的正确性，需要向对方发送确认响应ACK，又因为这些数据还没有被应用进程取走，这时候便需要进行窗口合拢，缓冲区的窗口左边缘向右滑动。注意响应的ACK序号是对方发送数据包的序号，一个对方发送的序号，可能因为窗口张开会被响应（ACK）多次。
2、窗口张开：窗口收缩后，应用进程一旦从缓冲区中取出数据，TCP的滑动窗口需要进行扩张，这时候窗口的右边缘向右扩张，实际上窗口这是一个环形缓冲区，窗口的右边缘扩张会使用原来被应用进程取走内容的缓冲区。在窗口进行扩张后，需要使用ACK通知对端，这时候ACK的序号依然是上次确认收到包的序号。
3、窗口收缩，窗口的右边缘向左滑动，称为窗口收缩，Host Requirement RFC强烈建议不要这样做，但TCP必须能够在某一端产生这种情况时进行处理。
2.4.10 样例
-
public class TCPServer { -
public static void main(String[] args) throws IOException { -
System.out.println("TCP协议服务器启动。。。。"); -
//创建服务器端连接 -
ServerSocket serverSocket = new ServerSocket(8080); -
//接受客户端请求 阻塞功能 -
ExecutorService executorService = Executors.newCachedThreadPool(); -
try{ -
while(true){ -
Socket socket=serverSocket.accept(); -
executorService.execute(new Runnable() { -
@Override -
public void run() { -
try { -
InputStream inputStream = socket.getInputStream(); -
byte[] bytes=new byte[1024]; -
int len=inputStream.read(bytes); -
String result=new String(bytes,0,len); -
System.out.println("服务器端接受的内容:"+result); -
} catch (IOException e) { -
e.printStackTrace(); -
} -
} -
}); -
} -
} catch (Exception e){ -
e.printStackTrace(); -
} finally { -
serverSocket.close(); -
} -
} -
} -
//TCP客户端或者直接在浏览器输入127.0.0.1:8080访问 -
public class TCPClient { -
public static void main(String[] args) throws IOException { -
System.out.println("socket tcp客户端启动。。。。"); -
//创建Socket客户端 -
Socket socket=new Socket("127.0.0.1",8080); -
OutputStream outputStream=socket.getOutputStream(); -
outputStream.write("我是客户端001。。。".getBytes()); -
socket.close(); -
} -
}
2308
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
