Android Socket 知识点汇总
版权声明:这篇博客资料来源 https://blog.csdn.net/carson_ho/article/details/53366856 , 未经授权,严禁转发!
一、网络基础
1.1 计算机网络分层
计算机网络分为五层:物理层、数据链路层、网络层、运输层、应用层。
其中:
- 网络层:负责根据IP找到目的地址的主机
- 运输层:通过端口把数据传到目的主机的目的进程,来实现进程与进程之间的通信
1.2 端口号(port)
端口号规定为16位,即允许一个IP主机有2的16次方65535个不同的端口。其中:
- 0~1023:分配给系统的端口号,我们不可以乱用
-
1024~49151:登记端口号,主要是让第三方应用使用,但是必须在IANA(互联网数字分配机构)按照规定手续登记,
-
49152~65535:短暂端口号,是留给客户进程选择暂时使用,一个进程使用完就可以供其他进程使用。在Socket使用时,可以用1024~65535的端口号
1.3 C/S结构
定义:即客户端/服务器结构,是软件系统体系结构
作用:充分利用两端硬件环境的优势,将任务合理分配到Client端和Server端来实现,降低了系统的通讯开销。
Socket正是使用这种结构建立连接的,一个套接字接客户端,一个套接字接服务器。
可以看出,Socket的使用可以基于TCP或者UDP协议。
1.4 TCP协议
定义:Transmission Control Protocol,即传输控制协议,是一种传输层通信协议
基于TCP的应用层协议有FTP、Telnet、SMTP、HTTP、POP3与DNS。
特点:面向连接、面向字节流、全双工通信、可靠。
-
面向连接:指的是要使用TCP传输数据,必须先建立TCP连接,传输完成后释放连接,就像打电话一样必须先拨号建立一条连接,打完后挂机释放连接。
-
全双工通信:即一旦建立了TCP连接,通信双方可以在任何时候都能发送数据。
-
可靠的:指的是通过TCP连接传送的数据,无差错,不丢失,不重复,并且按序到达。
-
面向字节流:流,指的是流入到进程或从进程流出的字符序列。简单来说,虽然有时候要传输的数据流太大,TCP报文长度有限制,不能一次传输完,要把它分为好几个数据块,但是由于可靠性保证,接收方可以按顺序接收数据块然后重新组成分块之前的数据流,所以TCP看起来就像直接互相传输字节流一样,面向字节流。
TCP建立连接 :
必须进行三次握手:若A要与B进行连接,则必须
- 第一次握手:建立连接。客户端发送连接请求报文段,将SYN位置为1,Sequence Number为x;然后,客户端进入SYN_SEND状态,等待服务器的确认。即A发送信息给B
- 第二次握手:服务器收到客户端的SYN报文段,需要对这个SYN报文段进行确认。即B收到连接信息后向A返回确认信息
- 第三次握手:客户端收到服务器的(SYN+ACK)报文段,并向服务器发送ACK报文段。即A收到确认信息后再次向B返回确认连接信息
此时,A告诉自己上层连接建立;B收到连接信息后告诉上层连接建立。
这样就完成TCP三次握手 = 一条TCP连接建立完成 = 可以开始发送数据
- 三次握手期间任何一次未收到对面回复都要重发。
- 最后一个确认报文段发送完毕以后,客户端和服务器端都进入ESTABLISHED状态。
为什么TCP建立连接需要三次握手?
答:防止服务器端因为接收了早已失效的连接请求报文从而一直等待客户端请求,从而浪费资源
- “已失效的连接请求报文段”的产生在这样一种情况下:Client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。
- 这是一个早已失效的报文段。但Server收到此失效的连接请求报文段后,就误认为是Client再次发出的一个新的连接请求。
- 于是就向Client发出确认报文段,同意建立连接。
- 假设不采用“三次握手”:只要Server发出确认,新的连接就建立了。
- 由于现在Client并没有发出建立连接的请求,因此不会向Server发送数据。
- 但Server却以为新的运输连接已经建立,并一直等待Client发来数据。>- 这样,Server的资源就白白浪费掉了。
采用“三次握手”的办法可以防止上述现象发生:
- Client不会向Server的确认发出确认
- Server由于收不到确认,就知道Client并没有要求建立连接
-
所以Server不会等待Client发送数据,资源就没有被浪费
-
TCP释放连接
TCP释放连接需要四次挥手过程,现在假设A主动释放连接:(数据传输结束后,通信的双方都可释放连接)- 第一次挥手:A发送释放信息到B;(发出去之后,A->B发送数据这条路径就断了)
-
第二次挥手:B收到A的释放信息之后,回复确认释放的信息:我同意你的释放连接请求
-
第三次挥手:B发送“请求释放连接“信息给A
-
第四次挥手:A收到B发送的信息后向B发送确认释放信息:我同意你的释放连接请求
B收到确认信息后就会正式关闭连接;
A等待2MSL后依然没有收到回复,则证明B端已正常关闭,于是A关闭连接

为什么TCP释放连接需要四次挥手
为了保证双方都能通知对方“需要释放连接”,即在释放连接后都无法接收或发送消息给对方
- 需要明确的是:TCP是全双工模式,这意味着是双向都可以发送、接收的
- 释放连接的定义是:双方都无法接收或发送消息给对方,是双向的
- 当主机1发出“释放连接请求”(FIN报文段)时,只是表示主机1已经没有数据要发送 / 数据已经全部发送完毕;
但是,这个时候主机1还是可以接受来自主机2的数据。
- 当主机2返回“确认释放连接”信息(ACK报文段)时,表示它已经知道主机1没有数据发送了
但此时主机2还是可以发送数据给主机1 - 当主机2也发送了FIN报文段时,即告诉主机1我也没有数据要发送了
此时,主机1和2已经无法进行通信:主机1无法发送数据给主机2,主机2也无法发送数据给主机1,此时,TCP的连接才算释放。
1.5 UDP协议
-
定义:User Datagram Protocol,即用户数据报协议,是一种传输层通信协议。
基于UDP的应用层协议有TFTP、SNMP与DNS。
-
特点:无连接的、不可靠的、面向报文、没有拥塞控制
-
无连接的:和TCP要建立连接不同,UDP传输数据不需要建立连接,就像写信,在信封写上收信人名称、地址就可以交给邮局发送了,至于能不能送到,就要看邮局的送信能力和送信过程的困难程度了。
-
不可靠的:因为UDP发出去的数据包发出去就不管了,不管它会不会到达,所以很可能会出现丢包现象,使传输的数据出错。
-
面向报文:数据报文,就相当于一个数据包,应用层交给UDP多大的数据包,UDP就照样发送,不会像TCP那样拆分。
- 没有拥塞控制:拥塞,是指到达通信子网中某一部分的分组数量过多,使得该部分网络来不及处理,以致引起这部分乃至整个网络性能下降的现象,严重时甚至会导致网络通信业务陷入停顿,即出现死锁现象,就像交通堵塞一样。TCP建立连接后如果发送的数据因为信道质量的原因不能到达目的地,它会不断重发,有可能导致越来越塞,所以需要一个复杂的原理来控制拥塞。而UDP就没有这个烦恼,发出去就不管了。
-
-
应用场景
很多的实时应用(如IP电话、实时视频会议、某些多人同时在线游戏等)要求源主机以很定的速率发送数据,并且允许在网络发生拥塞时候丢失一些数据,但是要求不能有太大的延时,UDP就刚好适合这种要求。所以说,只有不适合的技术,没有真正没用的技术。
【重要说明】博文仅作为本人的学习记录,论点和观点仅代表个人而不代表技术的真理,目的是自我学习和有幸成为可以向他人分享的经验,因此有错误会虚心接受改正,但不代表此刻博文无误!
【博客园地址】叫我+V : http://www.cnblogs.com/wjw1014
【CSDN地址】叫我+V : https://wjw1014.blog.csdn.net/
【Gitee地址】叫我+V :https://gitee.com/wjw1014
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· AI与.NET技术实操系列:基于图像分类模型对图像进行分类
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 25岁的心里话
· 闲置电脑爆改个人服务器(超详细) #公网映射 #Vmware虚拟网络编辑器
· 基于 Docker 搭建 FRP 内网穿透开源项目(很简单哒)
· 零经验选手,Compose 一天开发一款小游戏!
· 一起来玩mcp_server_sqlite,让AI帮你做增删改查!!