网络开发套接字以及UDP、TCP协议
目录
一、Socket 套接字
1、Socket 套接字的概念
2、Socket 套接字分类
3、Java数据报套接字通信模型
4、Java流套接字通信模型
5、Socket编程注意事项
二、UDP数据报套接字编程
1、DatagramSocket API
2、DatagramPacket API
3、InetSocketAddress API
4、相关示例代码
三、TCP 流套接字编程
1、ServerSocket API
2、Socket API
3、TCP中的长短连接
4、相关代码示例
四、TCP协议简介
1、TCP的概念
2、TCP的可靠性
3、TCP原理
（1）确认应答机制
（2）超时重发机制
■没有收到数据，所以没应答
■收到数据，也应答了，但还没有传回来
4、TCP的缓冲区
5、TCP的连接以及连接管理
经典四次挥手
6、 CLOSE_WAIT 状态
特点
常考面试题
7、TIME_WAIT状态
特点
面试题1
8、TCP协议和应用层不同的观察现象
挥手阶段总结
9、TCP中的异常
10、收到异常的标志位 —— RST
11、流量控制
接收窗口
12、拥塞控制
整体步骤
面向字节流特性
13、总结部分
TCP segment Header部分总结讲解
14、滑动窗口何时变化
连接阶段的一些机制
忽略ack丢失
立即重传
更新接收窗口
延迟应答/捎带应答
TCP协议手动设置边界
五、UDP的简介
1、UDP的概念
2、UDP的特点
3、传输层的UDP
4、UDP的工作机制
5、UDP接收缓冲区
6、基于UDP的应用层协议
7、UDP小结
（1）发送
（2）接收
一、Socket 套接字
1、Socket 套接字的概念
Socket套接字，是由系统提供用于网络通信的技术，是基于TCP/IP协议的网络通信的基本操作单元。基 于Socket套接字的网络程序开发就是网络编程。
2、Socket 套接字分类
●流套接字：使用传输层TCP协议、
●数据报套接字：使用传输层UDP协议
●原始套接字 原始套接字用于自定义传输层协议，用于读写内核没有处理的IP协议数据。
3、Java数据报套接字通信模型
对于UDP协议来说，具有无连接，面向数据报的特征，即每次都是没有建立连接，并且一次发送全部数 据报，一次接收全部的数据报。
java中使用UDP协议通信，主要基于 DatagramSocket 类来创建数据报套接字，并使用 DatagramPacket 作为发送或接收的UDP数据报。对于一次发送及接收UDP数据报的流程如下：
以上只是一次发送端的UDP数据报发送，及接收端的数据报接收，并没有返回的数据。也就是只有请 求，没有响应。对于一个服务端来说，重要的是提供多个客户端的请求处理及响应，流程如下：
4、Java流套接字通信模型
5、Socket编程注意事项
●客户端和服务端：开发时，经常是基于一个主机开启两个进程作为客户端和服务端，但真实的场 景，一般都是不同主机。
●注意目的IP和目的端口号，标识了一次数据传输时要发送数据的终点主机和进程
●Socket编程我们是使用流套接字和数据报套接字，基于传输层的TCP或UDP协议，但应用层协议， 也需要考虑，这块我们在后续来说明如何设计应用层协议。
●关于端口被占用的问题
二、UDP数据报套接字编程
1、DatagramSocket API
DatagramSocket 是UDP Socket，用于发送和接收UDP数据报。
DatagramSocket 类简介 : 负责 UDP 数据的发送和接收 , 该类没有合并到 Socket API 中 , 因为在 Socket 协议中 , 必须要存在服务器端与客户端 , 在 UDP 中 , DatagramSocket 既是服务器又是客户端 , 其不需要监听端口 , 也不需要建立连接 。
注意：使用DatagramSocket(int port)可能会出现端口被占用的情况
一旦通信双方在逻辑意义上有了通信线路，双方的地位就平等了(谁都可以是发送方和接收方)，注意在通信结束后调用close方法进行资源的回收
2、DatagramPacket API
DatagramPacket类就是通信过程中的数据抽象
DatagramPacket是UDP Socket发送和接收的数据报。
获取对方的ip和端口号，getData方法是给接收者使用可以拿到对方进程发送的应用层数据
3、InetSocketAddress API
构造UDP发送的数据报时，需要传入 SocketAddress ，该对象可以使用 InetSocketAddress 来创 建。
4、相关示例代码
rocket_class_ds_web: javaweb的相关笔记都会在这里记录哦！！！ - Gitee.com
三、TCP 流套接字编程
1、ServerSocket API
ServerSocket 是创建TCP服务端Socket的API。
2、Socket API
Socket 是客户端Socket，或服务端中接收到客户端建立连接（accept方法）的请求后，返回的服务端 Socket。
不管是客户端还是服务端Socket，都是双方建立连接以后，保存的对端信息，及用来与对方收发数据的。
服务器的Socket对象是在accept()中获取到的，所以只有客户端的Socket对象需要手动化实例，这个构造方法就是提供给客户端使用的，传入服务器的ip+port就可以。
输入流就是给接收方使用的，输出流就是给发送方使用的
■关于输入流的使用：
● 如果直接进行二进制读取
byte[] buf=new byte[1024]; int n=inputStream.read(buf);
● 如果进行读取文本数据，建议直接使用Scanner封装InputStream后在使用
Scanner sc=new Scanner(inputStream,"UTF-8");
s.nextLine()...
■关于输出流的使用
●如果直接进行二进制的输出
outputStream.write(buf,offset,length);
●如果进行的是文本输出，建议OutputStream封装成OutStreamWriter再封装成PrintWriter
OutputStreamWriter osWriter=new OutputStreamWriter(outputStream,"UTF-8")；
PrinterWriyer writer=new PrintWrirter(osWriter);
writer.println(...);/writer.print(...);/writer.printf(format,...);
●最后记得刷新缓存区(flush)。
3、TCP中的长短连接
TCP发送数据时，需要先建立连接，什么时候关闭连接就决定是短连接还是长连接：
●短连接：每次接收到数据并返回响应后，都关闭连接，即是短连接。也就是说，短连接只能一次收发数 据。
●长连接：不关闭连接，一直保持连接状态，双方不停的收发数据，即是长连接。也就是说，长连接可以 多次收发数据。
对比以上长短连接，两者区别如下：
●建立连接、关闭连接的耗时：短连接每次请求、响应都需要建立连接，关闭连接；而长连接●只需要 第一次建立连接，之后的请求、响应都可以直接传输。相对来说建立连接，关闭连接也是要耗时 的，长连接效率更高。
●主动发送请求不同：短连接一般是客户端主动向服务端发送请求；而长连接可以是客户端主动发送 请求，也可以是服务端主动发。
●两者的使用场景有不同：短连接适用于客户端请求频率不高的场景，如浏览网页等。长连接适用于 客户端与服务端通信频繁的场景，如聊天室，实时游戏等。
4、相关代码示例
四、TCP协议简介
1、TCP的概念
TCP：传输控制协议
TCP，即Transmission Control Protocol，传输控制协议。人如其名，要对数据的传输进行一个详细的 控制。
2、TCP的可靠性
●TCP会尽自己所能，尽量发送数据给对方，但并不能保证100%发送给对方。
●TCP会在数据不能发送给对方的情况给应用层一个错误通知。
●TCP可以保障接收方严格按照发送时的数据顺序接收。
●TCP保障数据不会出现无意间的损坏(UDP也可以做到)。
●TCP尽可能在维护网络质量。
3、TCP原理
（1）确认应答机制
如果收到了确认就代表对方收到了数据，反之就是没有收到数据。当发送方同时发送了多个数据时，就需要哦使用序列号来确认究竟拿一个是对应的数据文件。
序列号的简单说明：
■ 编号
● 发送的数据编号——序列号(Sequence Number) SN
●确认的数据编号——确认序列号(Acknowledge Sequence Number)
■编号的规则
●每个字节占用一个号
●byte[] data={1,2,3,4,5} 假如1的编号是a，那么5的编号就是a+4
注意：发送的起始第一个字节不一定就是0，而是一个随机值，第一个字节称为初始序列号
SN在发送TCP Segment 的 Header 中如何体现：
TCP 发送和接收的完整数据内容一般称为Segment(段)，也就是header和payload的总和
我们一次会发送多个数据，又因为byte[]数组的连续性，所以我们SN直接填写本次发送数据的第一个字节的数据编号即可。
在Header中，我们会保存payload中第一个字节的数据（SN编号），这样编号就变得可用了，在我们发送的时候，发送这个字节数据即可，segent会承担payload的长度
ASN的填写规则：
在header中，就是32位确认序号那一栏
ASN表示要接收的下一个字节的数据，把它传回给发送端，发送端就知道发什么了
ISN指数据的第一个字节编号，一般不会从0开始，这是处于安全角度考虑，以防恶意用户推测出合法的SN值来加以利用。
TCP segment扮演角色
segement就是上图的完整内容合并，它不仅可以担任send的角色，当我们标志位开关被打开时，也具有acknowledge segment的功能。
开关在header中的体现：
（2）超时重发机制
假设在接收方正常工作的情况在，超过一定的时间没有返回确认信号，就要进行重发。
关于重发的两种情况：
■没有收到数据，所以没应答
●有可能是数据还在路上
●有可能数据已经丢失了
■收到数据，也应答了，但还没有传回来
●有可能还在路上
●丢失
我们可以通过设定合理超时时间，解决在路上的问题，我们可以多等一会儿，再不来，那就只可能是丢失了。
■数据在何时选择重发
无论是数据已经丢包，还是数据正在半路，只要超时没有收到ack，我们都可以选择无脑重发数据■重发失败处理
当尝试几次重发后还是收不到ack，我们就停止发送。这里TCP已经用自己最大努力了接下来，可以这样操作：
1.通知应用层，发送失败(一般在write()中就会抛出异常)
2.尽自己最大努力再尝试联系一下(reset segment) ：最后的尝试，没收到也就没收到了
4、TCP的缓冲区
由于TCP要做到应答机制，当通过TCP发送出去的数据，需要进行短暂的保留，在应答之前，将数据保留以进行超时重传。因此TCP是由缓冲区的(暂存未应答的数据)，TCP也有接收缓冲区(当接收到数据后，应用层不一定理解就拿走了)。
5、TCP的连接以及连接管理
连接是一个抽象概念，说白了就是两台主机的相互连接，可以进行信息交互
连接的3个阶段，前后两个阶段只占据一点点时间
握手阶段：双方户型同步信息
握手的过程：
syn标志位及携带数据问题
同样在header标志位中，打开开关，即可同步
当我们第一次建立同步时，是不可以携带数据的，因为不知道能不能连接上
虽然不携带数据，但syn同样会消耗序列号
三次握手：上述中描述我们可以看出，两端之间有三次的互通过程，之后可以正常使用，这个就叫做三次握手
1.为什么要有握手阶段(同步阶段)︰为了可靠性，确保对方在线&&需要同步给对方一些基本信息2.为什么标志位叫做 syn(是同步synchronize的缩写)
3.为什么是三次握手。逻辑上是4次，合并是3次。少了哪个都不完整，多了没必要4.三次握手过程中的双方:主动连接方、被动连接方
5.三次握手过程中的标志位变化: syn / syn + ack / ack6.三次握手过程中携带数据情况:不能/不能/允许
7.三次握手过程中的SN/ASN变化: a 0 / b a+1 / a+1 b+1
三次握手过程中的状态转移就是当我发送端发syn的时候起，接收方就会被打开，然后进行我们的三次握手过程就完事了
四次握手阶段：
标志位：（FIN）Final/Finish
挥手也分为主动挥手和被动挥手，但不意味着主动挥手方就是主动连接方
若两方连接同时关闭，那么两端都是主动连接方
经典四次挥手
经典的四次挥手和握手差不多，只不过并没有合并syn和ack
但是握手的时候时必须合并的
经典挥手的状态转移
双方的起点都是established状态
然后，经过主动挥手方的FIN，然后被动挥手方回应ack。当一段时间过去后，被动挥手方发送FIN和ack。
挥手变形
三次挥手：
挥手的segment也是可以合并的，只不过因为握手必须合并，所以握手只能是三次
落实到状态转移图上就是：
这张图有点问题，在我看来close_wait状态之后再进行ACK和FIN的发送
同时关闭
两端自己发送FIN 和 ACK
落实到状态转移图上就是：
6、 CLOSE_WAIT 状态
特点
1.此状态发生在被动方
2.在单方面分手时，会出现这种情况
常考面试题
当服务器出现大量CLOSE_WAIT状态的TCP连接，这种现象是否合理？
答：合理与否要看具体情况：
1.如果是因为程序设计时，会出现比较长时间的单方面关闭情况，就是合理的。
2.如果不是的话就不合理，大概率是出现CLOSE_WAIT这一端的socket.close()忘记关闭了。
7、TIME_WAIT状态
特点
1.发生在主动方
2.在挥手基本结束的情况下出现
面试题1
问：既然回收的工作完成了，不是直接进入CLOSED状态，而是进入TIMED_WAIT状态呢？
当进入这个状态，而不是直接进入CLOSED状态，主要原因是因为我们还要发送一个ack文件，我们不知道能不能发送成功，所以不能立刻放开连接，得再等一段时间。
情况一：
对方没有收到ack的话，就会重发FIN，这个时候要是释放连接了就不知道咋办了。
情况二：
我们知道连接是通过五元组信息确定通路的，那么如果我不经过TIMED_WAIT 把五元组直接分配出去的话，这个五元组在收到信息算谁的就不好说了。
为什么TIME_WAIT时间是2MSL？
MSL: Maximum Segment Live:一个Segment能在网络上活着的最大时间。2*MSL时间过去之后，segment的一个来回肯定是够了。
说明:
1.对方"一定“最后一个ack (即使对方没有收到，再发送的fin我们也没有收到，说明网络出问题)
2.网络上肯定没有发送给甲的segment 了，所以收到的segment一定是给乙的
ps：
MSL是个理论值，实际中很多OS 取的是经验值，一般取1分钟。所以默认情况下，
TIME_WAIT持续的时间是2分钟。但这个值可以修改。
面试题2
当服务器出现大量TIMED_WAIT状态的TCP连接，这种现象是否合理？
理论上说，合理，我们只是正常进行关闭程序
但事实上这样不太好
维护连接是需要成本的(最主要的比如硬件中的内存) ，就算是我可以背负这个成本，最好也是由客户端来背负而非服务器，因为服务器需要连接的太多了，客户端相对会轻松很多。
所以，一般做网络编程设计时，也不推荐服务器主动关闭连接(排除某些情况)
8、TCP协议和应用层不同的观察现象
TCP能看到的就是三次握手过程 ——>建立连接 ——> 四次挥手
应用层能看到的基本上是一个代码的过程
另外要说的一点是，主被动连接方，发送接收者，主被动关闭方之间没有关系，不可以混为一谈。
挥手阶段总结
1.四次挥手，为啥不说三次。
2.四次挥手的三种情况
3.四次挥手的tcp header的标志位变化
4.四次挥手的状态变化
5.其中CLOSE_WAIT和TIME_WAIT做重点学习。
9、TCP中的异常
连接起来的两个进程究竟在何时抛出异常，何时正常处理捏，我们分为这几种情况。
大情况1：OS正常参与操作来关闭连接
1.任务管理器结束
2.关机结束
3.重启结束
都是正常关闭socket.close
大情况2：OS代码执行不了—长按关机键/断开电源
我们需要分开讨论连接最后的处理情况：
例如甲乙主机相连，我们断开甲的连接
首先，要分析甲主机的命运
甲主机没有进行任何OS操作，直接消失在连接中，不是正常关闭，也不是异常关闭，是直接消失
再来分析乙如何处理
在乙的世界中，目前的连接并未断开，我也不知道甲已经消失了。因此，我们需要看情况讨论接下来的处理
1.如果乙中存在写事件
这样的话就比较容易办了，那边收不到消息就发不回来ack，过一段时间就会发生超时重传，如果重传尝试多次未果，我们会走异常处理：
1.关闭该TCP连接
2.以异常的方式通知应用层(Java)
3.再发最后一条 reset segment 来通知对方，该连接异常关闭了，对方收得到收得到与我无关了
2.如果只存在读事件
如果只是读数据的话，本来也就不会收到ack，这样的话我们咋办呢？
1.TCP的keeyalive机制 ： 就算我们只读数据，我们也会定期发送一些数据给对方(数据内容可以为空)，目的就是看看对方有没有ack发送回来(使用不多)
2.应用层自己做工作：
1).我们 read 的时候，加上一个超时时间 —— read timeout
2).定期双方给对方发消息 —— heartbeat(心跳包)
10、收到异常的标志位 —— RST
Reset segment
当我们收到这个标志位打开的segment时就说明异常了，我们需要立刻关闭连接(不需要挥手)，并且以异常的方式通知应用层
11、流量控制
通过对方的接受能力来控制自己的发送量。
流量控制分为以下几步：
知道对象的接收能力——拿到对方的接收能力——通过发送方滑动窗口机制来控制发送量
接收窗口
首先我们理解一下接收窗口的概念：
接收窗口是接收缓冲区的未使用大小
1.如何实时地知道对方的接收能力呢？
当然是要对方来告诉我们，对方可以通过以下方式告诉我们信息：
1.在所有要发送的segment中携带接收能力（接收窗口）
2.即使有一段时间不发送数据，也要发送ack+window给对方
2.当拿到对方的接受能力，准备发送流量
我们的最大发送量其实就是对方的接收窗口大小。
3.滑动窗口机制
滑动窗口存在于发送缓冲区，我们应用层会把所有需要发送的数据放入缓冲区，然后我们滑动窗口就是在这个数据中的一个窗口，但大小由接收缓冲区的window决定，会实时变化。
第一步：三次握手，可以在自己的发送区来划分得到对象的接收窗口大小。
第二步：由应用层写入需要发送的所有数据
这里可能滑动窗口很大，我们可以把数据全部放在滑动窗口里，不然会溢出，存在于滑动窗口外。
第三步：发送一部分数据到接收端
四步：根据返回来的ack和新的接收窗口，改变滑动窗口
ack已应答的数据就说明对方的应用层已经接收了，这是唯一可以使我们的滑动窗口左侧向前移动的方式。
至于滑动窗口的右侧向前移动的方式，由接收端发送回来segment中的接收窗口来决定，我们的滑动窗口就是这个大小。
12、拥塞控制
拥塞控制就是广义上流量控制的另外一种判断方式，他通过网络的承载能力来对发送量进行控制，不同于接收窗口那种直接能得到信息的形式，拥塞窗口是需要计算的。
拥塞窗口
拥塞窗口不是一个精确值，而是一个通过动态算法计算出来的估算值。
我们将丢包率作为重要因素来推算拥塞窗口
丢包率 = 单位时间内，TCP重发的次数占比。
整体步骤
1.得到接收窗口和拥塞窗口大小。
2.发送最大流量的大小就是 min(接收窗口，拥塞窗口)
3.根据以上结果构造滑动窗口
面向字节流特性
正因为由流量控制，拥塞窗口的特性，我们无法一次性把数据全部发送过去，所以TCP是面向字节流的。
13、总结部分
TCP segment Header部分总结讲解
Header部分基本都说了，下图中对两个还没讲的标志位进行了说明，并对之前说的内容进行了总结。
TCP Connection整体过程总结
落实在状态转移上，我们能记住三次握手就可以，能多记就多记
14、滑动窗口何时变化
这个上面也讲了，
左侧只随着ack里面已接收数据的大小而改变
右侧要看流量控制后，接收窗口和拥塞窗口的大小，还要看ack，也就是左侧如何变化的，右侧可以同时右移。
连接阶段的一些机制
忽略ack丢失
这是种特殊情况，当我们中间的ack没收到，但是后面的ack收到了，就不需要管前面了。
立即重传
默认情况是：超时重传
我们现在说的情况是： 当连续收到相同ASN时，直接重传
更新接收窗口
即使一段时间内没数据，也要发送自己的接收窗口大小给对方。
延迟应答/捎带应答
可以来延缓应答时间，这个叫延迟应答，如果下一次数据也来了，那么我一起应答回去就好了，
我们在发送数据回去时，也可以发送应答回去，这个叫捎带应答，两个可以配合使用。
TCP协议手动设置边界
应用层的协议设计是我们必须手动设置边界
方法：
1.发送定长消息
2.先发长度，再发数据
3.用特殊字符分隔
TCP协议总结
TCP与UDP对比
五、UDP的简介
1、UDP的概念
UDP:用户报文协议
UDP 是User Datagram Protocol的简称， 中文名是用户数据报协议，是OSI(Open System Interconnection，开放式系统互联) 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务
2、UDP的特点
无连接：知道对端的IP和端口号就直接进行传输，不需要建立连接
不可靠：没有任何安全机制，发送端发送数据报以后，如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息
面向数据报：应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并
缓冲区：UDP只有接收缓冲区，没有发送缓冲区
大小受限：UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K（包含UDP首部）
3、传输层的UDP
User Datagram Protocal 用户报文协议
Udp是一个简单的传输层协议，它只是做到了传输层最基本的职责(在host to host的情况下，实现process to process)
由于网络层本身是不可靠的，UDP又没有做过任何的处理，所以UDP也是不可靠的(由于UDP什么也没有做，所以就把网络层的不可靠性直接带到了应用层，因此站在应用层的角度来看，UDP是不可靠的)
4、UDP的工作机制
UDP的报头(header)，可以理解成就是快递单上的地址
payload也就是数据内容，由应用层提供再由传输层打包
那么UDP的职责就是将应用层的payload打包，贴上标签，然后就往网络层发送
至于到没到接收者手里，发送者无从知晓。
UDP长度：指的就是整个报文的长度
UDP校验和：通常用来在通信中，尤其是远距离通信中保证数据的完整性和准确性
基本原理：利用hash函数(chechsum函数就是一种hash函数),只要是相同的数据经过函数处理之后就一定可以得到相同的结果(hash值：checksum)
5、UDP接收缓冲区
从应用层到数据链路层中，保存数据的区域都可以称为缓冲区，概念比较抽象
在应用层中的UDP协议，是没有发送缓冲区的，只有接收缓冲区
我们理解为，接收方的UDP接收到数据后，不需要立刻被应用层拿走，放在接收缓冲区默默等待即可，但如果应用层在接收缓冲区没有东西的时候去拿数据，又没有超时机制的话，就会死等了。一句话，UDP只要把数据放到网上那就是发送成功了，收没收到跟我没关系
6、基于UDP的应用层协议
NFS：网络文件系统
TFTP：简单文件传输协议
DHCP：动态主机配置协议
BOOTP：启动协议（用于无盘设备启动）
DNS：域名解析协议
当然，也包括你自己写UDP程序时自定义的应用层协议。
7、UDP小结
（1）发送
1.从应用层先收到payload数据，相当于把应用层的内存数据拷贝到自己的内核内存区域
2.准备header部分：
1).源端口(socket里就有，也不用自己写)
2).目标端口
3).UDP长度
4).checksum
3.header+payload 就相当于 datagram
4.直接把打包好的datagram交给网络层发送
5.只要网络层发送成功(数据已经到达网卡)
6.通知应用层发送成功
如果接收方能收到，一定是原封不动完好无损的数据，这就是面向数据报文的好处
（2）接收
1.将从网络层收到的包裹放到内核缓冲区
2.通过header定长，把包裹分解为header部分和payload部分 - 解包
3.读取header部分，包括端口，ip信息，checksum(校验和)，长度等
4.长度不对直接扔，谁也不需要告诉
5.checksum(校验和)不对直接扔
6.把payload放到接收缓冲区
7.通知应用层数据到了
8.应用层来取
9.应用层一直不来，信息照样可以扔
网络开发套接字以及UDP、TCP协议相关推荐
- Linux网络-UDP/TCP协议详解
Linux网络-UDP/TCP协议详解 零.前言 一.UDP协议 二.TCP协议 1.应答机制 2.序号机制 3.超时重传机制 4.连接管理机制 三次握手 四次挥手 5.理解CLOSE_WAIT状态 ...
- 自定义Udp/Tcp协议，通信协议Socket/WebSocket，IM粘包、分包解决等(2)，ProtocolBuffer
> 自定义Udp/Tcp协议/通信协议(Java/C):自定义构建和解析IM协议消息:IM自定义UDP通信协议 类似于网络通信中的TCPIP协议一般,比较可靠的通信协议往往包含有以下几个组成 ...
- Python网络编程——socket套接字实现UDP/TCP信息传输
socket套接字 socket(简称 套接字) ,是支持TCP/IP的网络通信的基本操作单元,可以看做是不同主机之间的进程进行双向通信的端点,简单的说就是通信的两方的一种约定,用套接字中的相关函数来 ...
- 计算机网络-运输层（UDP/TCP协议）
文章目录 前言 一.计算机网络 二.运输层 1.复用和分用 2.UDP 3.TCP Ⅰ- TCP的灵魂拷问 - TCP 和 UDP 的区别 Ⅱ - TCP的灵魂拷问 - 三次握手 Ⅲ - TCP的灵魂 ...
- linux网络编程IPv6socket,简单的IPv6 UDP/TCP socket编程 -- 两台Linux实现简单的ipv6通信...
配置: 1.两台linux用网线直接相连 2.手动配置两台linux的ipv6地址为: ifconfig eth0 add 2001:da8:e000::1:1:1 ifconfig eth0 add ...
- HTML5链接tcpUDP,UDP/TCP协议 网络调试工具源码(C#)
本代码包括了TCP和UDP的客户端和服务端,适合C#初学者学习.参考 资源下载此资源下载价格为2D币,请先登录 资源文件列表 NetWork/NetWork.sln , 990 NetWork/Net ...
- 流式套接字：基于TCP协议的Socket网络编程（案例2）
案例:在案例1的基础上实现一个服务器对应多个客户端(多线程),且获得每个客户端的IP. 线程代码: package com.yh.mySocket;import java.io.BufferedRea ...
- java udp tcp协议_【java】TCP和UDP传输协议
TCP协议和UDP协议的比较 TCP的全称是Transmission Control Protocol (传输控制协议) 传输控制协议,是一种面向连接的协议,类似打电话 在通信的整个过程中保持连接 保 ...
- {网络编程}和{多线程}应用：基于TCP协议【实现多个客户端发送文件给一个服务器端】--练习
要求: 实现多个客户端发送文件给一个服务器端提示:多个人创建客户端发送文件,服务端循环接收socket,从socket中获取文件 说明:这里我们只要建立一个服务端就可以了,然后让多台电脑使用客户端给这 ...
最新文章
- 怎样用c语言写高速超速罚款标准,pta高速公路超速处罚（C语言）
- Java中switch语句支持的类型
- SpringBoot入门篇之properties中定义user.name失效解决
- 简单的绑定数据截取时间字符年月日
- android7.1 repo,RK3399 Android 7.1 删除repo后编译报错
- Spark SQL案例：分组排行榜
- matlab生成的图片有边,科学网—图片空白边缘处理/统计直方图---matlab/保存生成高质量的清晰图 - 杨小林的博文...
- 常用正则表达式匹配Antconc英文句式搭配
- 通信方式、通信接口、通信总线、通信协议的关系
- Sql取出各科分数前三名的学生，Sql各科成绩前三的学生
- 如何录用有竞业限制协议的员工？
- 2022年瑞典经济发展研究报告
- java跨域问题Response to preflight request doesn‘t pass access control check: No ‘Access-Control-Allow-Or
- 扑克牌游戏——C语言
- Mongodb节点同步失败状态“ RECOVERING ”恢复
- Windows操作系统名称与版本号汇总
- vijos 清点人数
- 用不可逆算法MD5进行加密后，如何进行登录验证
- 关于我求是不是质数的一个错误，输入9判断是质数的原因
- python给图片加滤镜的方程_清明节来了，我们用Python给《清明上河图》加了个滤镜...