网络编程
网络架构及其演变过程
单机架构
应用领域：
* 植物大战僵尸
* office
CS架构
应用领域：
* QQ
* 大型网络游戏
计算机发展初期用户去取数据，直接就去主机拿，从这里开始就分出了客户端和服务端。
客户端：用户安装的软件；
服务端：统一管理数据库的主机中的软件就叫做服务端，再后来服务端不只是管理数据，外加处理业务逻辑。
cs架构要求
-
用户操作系统安装客户端；产商操作系统部署服务端
-
每个用户需要独立安装软件、服务端升级也要每个用户升级
数据放在服务端和客户端的利与弊
-
服务端统一处理有更好的安全性和稳定性而且升级比较容易，不过服务器负担就增加了。
-
客户端将负担分配到每个用户，从而可以节约服务器资源，安全性和稳定性可能会有一定的问题，但是升级比较麻烦，每个安装的客户端程序都需要升级，另外为了节省网络资源，通过网络传输的数据应该尽量减少
BS架构
应用领域：
* 淘宝网页
* 京东网页
统一客户端即默认安装用户电脑中的浏览器，访问同种类的网站，具体业务的处理根据相应协议和标准提供通用的服务器程序，在不同的服务器处理。
两种BS架构
TCP/IP的对应关系，就像我们在淘宝购物，所在位置有的快递（网络接入层），告诉卖家地址（网络互联层）、快递送货（运输层）、收到货物拆包使用（应用层）。
注意：对于广泛使用的东西就需要制定相应的标准，就像大公司有很多制度来规范做事情的流程。由于网络传输应用非常广泛，但是规矩不是强制性的，所以叫做协议而不是标准，TCP/IP参考模型也可以看做是一种协议。BS结构中TCP/IP模型中的网络接入层没有响应的协议，网络互联层是IP协议，传输层是TCP协议，应用层是HTTP协议，另外还是用到了DNS结构，而且在HTTP上层还有相应。
基于BS结构下的程序就要求解决速度问题，而速度问题的核心就是解决海量数据操作和高并发问题，网站复杂架构就是从这两个问题演变出来的。
OSI七层协议
互联网的本质就是一系列的网络协议，这个协议就叫OSI协议（一系列协议），按照功能不同，分工不同，人为的分层七层。实际上这个七层是不存在的。没有这七层的概念，只是人为的划分而已。区分出来的目的只是让你明白哪一层是干什么用的。
每一层都运行不同的协议。协议是干什么的，协议就是标准。
实际上还有人把它划成五层、四层。
- 七层划分为：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。
- 五层划分为：应用层、传输层、网络层、数据链路层、物理层。
- 四层划分为：应用层、传输层、网络层、网络接口层。
物理层
物理层功能：主要是基于电器特性发送高低电压(电信号)，高电压对应数字1，低电压对应数字0
物理层字面意思解释：物理传输、硬件、物理特性。在深圳的你与北京的朋友聊天，你的电脑必须要能上网，物理体现是什么？是不是接一根网线，插个路由器，北京的朋友那边是不是也有根网线，也得插个路由器。也就是说计算机与计算机之间的通信，必须要有底层物理层方面的连通，就类似于你打电话，中间是不是必须得连电话线。
中间的物理链接可以是光缆、电缆、双绞线、无线电波。中间传的是电信号，即010101...这些二进制位。
要让这些010010101001...有意思，人为的分组再适合不过了，8位一组，发送及接收都按照8位一组来划分。接收到8位为一组的话，那么就可以按照这8位数来做运算。如果没有分组，对方接收的计算机根本就不知道从哪一位开始来做计算，也解析不了收到的数据。我发了16位你就按照16位来做计算吗？我发100位你就按照100位做计算吗？没什么意义是吧。因此要想让底层的电信号有意义，必须要把底层的电信号做分组。我做好8位一组，那么我收到数据，我就知道这几个8位做一组，这几个8位做一组。那么每个8位就可以得到一个确定的数。分组是谁干的活呢？物理层干不了，这个是数据链路层干的。
数据链路层
数据链路层由来：单纯的电信号0和1没有任何意义，必须规定电信号多少位一组，每组什么意思
数据链路层的功能：定义了电信号的分组方式
以太网协议
早期的时候：
数据链路层就是来对电信号来做分组的。以前每个公司都有自己的分组方式，后来形成统一的标准，即以太网协议ethernet。
ethernet规定：一组电信号构成一个数据报，叫作'帧'，每一数据帧分成：报头head和数据data两部分
- head包含：（固定18个字节）
- 发送者/源地址，6个字节
- 接受者/目标地址，6个字节
- 数据类型，6个字节
- data包含：（最短46字节，最长1500字节）
- 数据报的具体内容：head长度 + data长度 = 最短64字节，最长1518字节，超过最大限制就分片发送
Mac地址
head中包含的源和目标地址由来：ethernet规定接入Internet的设备都必须具备网卡，发送端和接收端的地址便是指网卡的地址，即Mac地址
- Mac地址：每块网卡出厂时都被烧制上一个世界唯一的Mac地址，长度为48位2进制，通常由12位16进制数表示（前六位是厂商编号，后六位是流水线号）
广播地址
有了Mac地址以后，计算机就可以通用了，假设一个教室就是一个局域网（隔离的网络），这个教室里面有几台计算机，计算机的通信和人的通信是一个道理，把教室里面的人都比作一个个计算机，假设教室里面的人都是瞎子，其实计算机就是瞎子的，计算机通信基本靠吼，现在我要找教室里面的飞哥要战狼2的片，然后我就吼一声，说我要找飞哥要战狼2的片，战狼2的片就属于我的数据，但是我在发的时候我是不是要标识我是谁，我要找谁，我是谁就是我的Mac地址，我要找谁就是飞哥的Mac地址，这两个地址做数据包的头部，再加上数据战狼2的片就构成了一个数据帧。
这个数据包封装好以后就往外发，到物理层以后就全部转成二进制，往外发是怎么发的呢？就是靠吼。即“我是nick，我找飞哥要战狼2的片”。这么吼了一嗓子以后，全屋子的人都能听到，这就是广播。
广播出去以后，所有人都听得见，所有人都会拆开这个包，读发送者是谁，接收者是谁，只要接收者不是自己就丢弃掉。对计算机来说，它会看自己的Mac地址，飞哥收到以后，他就会把片发给我，发送回来同样采用广播的方式了，靠吼。
同一个教室（同一个局域网）的计算机靠吼来通信，那不同教室的计算机又如何？
比如说局域网1的pc1与局域网2的pc10如何通信？你在教室1（局域网1）吼，教室2（局域网2）的人肯定是听不见的。这就是跨网络进行通信，数据链路层就解决不了这个问题了，这就得靠网络层出面了。
注意：在讲网络层之前，其实基于广播的这种通信就可以实现全世界通信了，你吼一声，如果全世界是一个局域网，全世界的计算机肯定可以听得见，从理论上似乎行得通，如果全世界的计算机都在吼，你想一想，这是不是一个灾难。因此，全世界不能是一个局域网。于是就有了网络层。
网络层
网络层功能：引入一套新的地址用来区分不同的广播域/子网，这套地址即网络地址
网络层的由来：有了ethernet、Mac地址、广播的发送方式，世界上的计算机就可以彼此通信了，问题是世界范围的互联网是由一个个彼此隔离的小的局域网组成的，那么如果所有的通信都采用以太网的广播方式，那么一台机器发送的包全世界都会收到
- 对于上述的问题这就不仅仅是效率低的问题了，这会是一种灾难
为了解决上述灾难，网络层定义了一个IP协议，你想，我是这个教室的一个学生，我想找隔壁教室一个叫老王的学生，我也不认识老王，那怎么办，我吼？老王在另外一个教室肯定是听不到的。找教室的负责人，这个教室的负责人就负责和隔壁教室的负责人说话，说我们教室的有个学生要找你们教室的老王。往外传的东西交给负责人就可以了，内部的话上面已经提到，通过广播的方式，对外的东西广播失效。教室的负责人就是网关，网关即网络关口的意思。
Mac地址是用来标识你这个教室的某个位置，IP地址是用来标识你在哪个教室（哪个局域网）。你要跨网络发包你是不是要知道对方的IP地址，比如你要访问百度，你肯定得知道百度服务器的IP地址。计算机在发包前，会判断你在哪个教室，对方在哪个教室，如果在一个教室，基于Mac地址的广播发包就OK了；如果不在一个教室，即跨网络发包，那么就会把你的包交给教室负责人（网关）来转发。Mac地址及IP地址唯一标识了你在互联网中的位置。
数据链路层中会把网络层的数据包封装到数数据链路层的数据位置，然后再添加上自己的包头，再发给物理层，物理层发给网关，网关再发给对方教室的网关，对方教室的网关收到后在那个教室做广播。
在数据链路层看，数据封装了两层，跟玩俄罗斯套娃有点类似，一层套了一层。
局域网中怎么获取对方的Mac地址：
肯定要知道对方的IP地址，这是最基本的，就像你要访问百度，肯定得知道百度的域名，域名就是百度的IP地址。自己的IP可以轻松获得，自己的Mac也轻松获取，目标Mac为12个F，我们叫广播地址，表达的意思是我想要获取这个目标IP地址172.16.10.11的机器的Mac地址。Mac为12个F代表的是一种功能，这个功能就是获取对方的Mac地址，计算机的Mac永远不可能是12个F。假设是在本教室广播，一嗓子吼出去了，所有人开始解包，只有IP地址是172.16.10.11的这个人才会返回他的Mac地址，其他人全部丢弃。发回来源Mac改成飞哥自己的Mac地址，同时把飞哥的Mac地址放在数据部分。
跨网络怎么获取对方的Mac地址：
通过IP地址区分，计算机运算判断出飞哥不在同一个教室，目标IP就变成了网关的IP了。网关的IP在计算机上配死了，可以轻松获取。
注意：网关帮你去找飞哥，但对用户来说，由于速度太快我们根本就感觉不到网关的存在。
IP协议详解
规定网络地址的协议叫IP协议，它定义的地址称之为IP地址，广泛采用v4版本即IPv4，它规定网络地址由32位2进制表示
范围0.0.0.0-255.255.255.255
- 一个IP地址通常写成四段十进制，例：172.16.10.1
IP地址的两部分
- 网络部分：标识子网
- 主机部分：标识主机
- 注意：单纯的IP地址段只是标识了IP地址的种类，从网络部分或主机部分都无法辨识一个IP所处的子网
例：172.16.10.1与172.16.10.2并不能确定二者处于同一子网
子网掩码详解
所谓”子网掩码”，就是表示子网络特征的一个参数。它在形式上等同于IP地址，也是一个32位二进制数字，它的网络部分全部为1，主机部分全部为0。比如，IP地址172.16.10.1，如果已知网络部分是前24位，主机部分是后8位，那么子网络掩码就是11111111.11111111.11111111.00000000，写成十进制就是255.255.255.0。
知道”子网掩码”后，我们就能判断，任意两个IP地址是否处在同一个子网络。方法是将两个IP地址与子网掩码分别进行AND运算（两个数位都为1，运算结果为1，否则为0），然后比较结果是否相同，如果是的话，就表明它们在同一个子网络中，否则就不是。
比如，已知IP地址172.16.10.1和172.16.10.2的子网掩码都是255.255.255.0，请问它们是否在同一个子网络？两者与子网掩码分别进行AND运算
- 172.16.10.1：10101100.00010000.00001010.000000001
- 255.255.255.0:11111111.11111111.11111111.00000000
- AND运算得网络地址结果：10101100.00010000.00001010.000000000->172.16.10.0
- 172.16.10.2：10101100.00010000.00001010.000000010
- 255.255.255.0:11111111.11111111.11111111.00000000
- AND运算得网络地址结果：10101100.00010000.00001010.000000000->172.16.10.0
- 结果都是172.16.10.0，因此它们在同一个子网络。
总结一下，IP协议的作用主要有两个，一个是为每一台计算机分配IP地址，另一个是确定哪些地址在同一个子网络。
IP数据包详解
IP数据包也分为head和data部分，无须为IP包定义单独的栏杆，直接放入以太网包的data部分
- head：长度为20到60字节
- data：最长为65515字节
注意：以太网数据包的“数据”部分，最长只有1500字节。因此，如果IP数据包1500字节，它就需要分割成几个以太网数据包，分开发送了。
有了Mac地址 + IP地址，我们就能确定世界上独一无二的一台计算机。
ARP协议详解
ARP协议由来：计算机通信基本靠吼，即广播的方式，所有上层的包到最后都要封装上以太网头，然后通过以太网协议发送，在谈及以太网协议的时候，我们了解到：通信是基于Mac的广播方式实现，计算机在发包时，获取自身的Mac是容易的，如何获取目标主机的Mac，就需要通过ARP协议
ARP协议功能：广播的方式发送数据包，获取目标主机的Mac地址
协议工作方式：每台主机IP都是已知的，例如：主机172.16.10.10/24访问172.16.10.11/24
传输层
传输层的由来：网络层的IP帮我们区分子网，以太网层的Mac帮我们找到主机，然后大家使用的都是应用程序，你的电脑上可能同时开启qq，暴风影音等多个应用程序。
那么我们通过IP和Mac找到了一台特定的主机，如何标识这台主机上的应用程序，答案就是端口，端口即应用程序与网卡关联的编号。
传输层功能：建立端口到端口的通信
补充：端口范围0-65535,0-1023为系统占用端口
- 有了Mac地址+IP地址+端口，我们就能确定世界上独一无二的一台计算机的应用程序
TCP协议
- 可靠传输，TCP数据包没有长度限制，理论上可以无限长，但是为了保证网络的效率，通常TCP数据包的长度不会超过IP数据包的长度，以确保单个TCP数据包不必再分割。
UCD协议
- 不可靠传输，“报头”部分一共只有8个字节，总长度不超过65535字节，正好放进一个IP数据包。
应用层
应用层由来：用户使用的都是应用程序，均工作于应用层，互联网是开发的，大家都可以开发自己的应用程序，数据多种多样，必须规定好数据的组织形式
应用层功能：规定应用程序的数据格式
- 例：TCP协议可以为各种各样的程序传递数据，比如Email、WWW、FTP等等。那么，必须有不同协议规定电子邮件、网页、FTP数据的格式，这些应用程序协议就构成了“应用层”。
Socket抽象层
我们知道两个进程如果需要进行通讯最基本的一个前提是能够唯一标示一个进程，在本地进程通讯中我们可以使用PID来唯一标示一个进程，但PID只在本地唯一，网络中的两个进程PID冲突几率很大，这时候我们需要另辟蹊径了，我们知道IP层地址可以唯一标示主机，而TCP层协议和端口号可以唯一标示主机的一个进程，这样我们可以利用IP地址+协议+端口号唯一标示网络中的一个进程。
能够唯一标示网络中的进程后，它们就可以利用Socket进行通信了，什么Socket呢？我们经常把Socket翻译为套接字，Socket是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应层调用已实现进程在网络中通信。
Socket起源于Unix一切皆文件哲学的思想下，Socket是一种“打开--读/写--关闭”模式的实现，服务器和客户端各自维护一个“文件”，在建立连接打开后，可以向自己文件写入内容供对方读取或者读取对方内容，通讯结束时关闭文件。
TCP三次握手和四次挥手
背景描述
通过OSI七层网络模型中IP层的介绍，我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。
UDP，在传送数据前不需要先建立连接，远地的主机在收到UDP报文后也不需要给出任何确认。虽然UDP不提供可靠交付，但是正是因为这样，省去和很多的开销，使得它的速度比较快，比如一些对实时性要求较高的服务，就常常使用的是UDP。对应的应用层的协议主要有 DNS，TFTP，DHCP，SNMP，NFS 等。
TCP，提供面向连接的服务，在传送数据之前必须先建立连接，数据传送完成后要释放连接。因此TCP是一种可靠的的运输服务，但是正因为这样，不可避免的增加了许多的开销，比如确认，流量控制等。对应的应用层的协议主要有 SMTP，TELNET，HTTP，FTP 等。
常用的熟知端口号
| 应用程序 | FTP | TFTP | TELNET | SMTP | DNS | HTTP | SSH | MYSQL |
|---|---|---|---|---|---|---|---|---|
| 熟知端口 | 21,20 | 69 | 23 | 25 | 53 | 80 | 22 | 3306 |
| 传输层协议 | TCP | UDP | TCP | TCP | UDP | TCP | TCP | TCP |
TCP概述
TCP把连接作为最基本的对象，每一条TCP连接都有两个端点，这种端点我们叫做套接字（socket），它的定义为端口号拼接到IP地址即构成了套接字，例如，若IP地址为192.3.4.16而端口号为80，那么得到的套接字为192.3.4.16:80.
TCP报文首部
- 源端口和目的端口，各占2个字节，分别写入源端口和目的端口；
- 序号，占4个字节，TCP连接中传送的字节流中的每个字节都按顺序编号。例如，一段报文的序号字段值是301，而携带的数据共有100字段，显然下一个报文段（如果还有的话）的数据序号应该从401开始；
- 确认好，占4个字节，是期望收到对方下个报文的第一个数据字节的序号。例如，B收到了A发送过来的报文，其序列号字段是501，而数据长度是200字节，这表明B正确的收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701；
- 数据偏移，占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远；
- 保留，占6位，保留今后使用，但目前应都为0；
- 紧急URG，当URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据；
- 确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；
- 推送PSH，当两个应用程序进行交互通信时，有时在一端的应用程序希望在键入一个命令后立即就能收到对方的响应，这时候就将PSH=1；
- 复位RST，当RST=1，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立连接；
- 同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1,ACK=1;
- 终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；
- 窗口，占2字节，指的是通知接收方，发送本报文你需要有多大的空间来接收；
- 检验和，占2字节，检验首部和数据这两部分；
- 紧急指针，占2字节，指出本报文段中的紧急数据的字节数；
- 选项，长度可变，定义一些其他的可选的参数。
TCP连接的建立（三次握手）
- 最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。
- TCP服务器进程先创建传输控制块TCB，时刻准备接受客户端进程的连接请求，此时服务器就进入了LISTEN（监听）状态；
- TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号seq=x，此时，TCP客户端进程进入了SYN-SENT（同步发送状态）状态。TCP规定，SYN报文段（SYN=1报文段）不能携带数据，但需要消耗掉一个序号。
- TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该ACK=1，SYN=1,确认号是ACK=x+1，同时也要为自己初始化一个序列号seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
- TCP客户端进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
- 当服务器收到客户端的确认后也进入ESTABLIHED状态，此后双方就可以开始通信了。
TCP四次挥手
- 数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLIHED状态，然后客户端主动关闭，服务器被动关闭。
- 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
- 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
- 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
- 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
- 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗ *∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
- 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
为什么客户端最后还要等待2MSL
MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。
- 保证客户端发送的最后一个ACK报文能够到达服务器，因此这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN-ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
- 防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
为什么建立连接是三次握手，关闭连接确是四次挥手
建立连接的时候，服务器在LISTEN状态，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。
如果已经建立了连接，但是客户端突然出现故障了怎么办
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
基于TCP协议的套接字编程
什么是Scoket
Scoket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Scoket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Scoket接口后面，对用户来说，一组简单的接口就是全部，让Scoket去组织数据，以符合指定的协议。
所以，我们无需深入理解TCP/UDP协议，Scoket已经为我们封装好了，我们只需要遵循Scoket的规定去编程，写出的程序自然就是遵循TCP/UDP标准的。
- 注意：也有人将Scoket说成IP+PORT,IP是用来标识互联网中的一台主机的位置，而port是用来标识这台机器上的一个应用程序，IP地址是配置到网卡上的，而port是应用程序开启的，IP与port的绑定就标识了互联网中独一无二的一个应用程序，而程序的pid是同一台机器上不同进程或者线程的标识。
套接字工作流程
一个生活中的场景。你要打电话给一个朋友，先拨号，朋友听到电话铃声后提起电话，这时你和你的朋友就建立起了连接，就可以讲话了。等交流结束，挂断电话结束此次交谈。生活中的场景就解释了这工作原理。
先从服务器端说起。服务器端先初始化Scoket，然后与端口绑定（bind），对端口进行监听（listen），调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Scoket。然后连接服务器（connect），如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束，使用以下Python代码实现：
import socket
# socket_family 可以是 AF_UNIX 或 AF_INET。socket_type
# 可以是 SOCK_STREAM 或 SOCK_DGRAM。protocol 一般不填，默认值为 0
socket.socket(socket_family, socket_type, protocal=0)
# 获取tcp/ip套接字
topSock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 获取udp/ip套接字
udpSock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# 由于socket模块中有太多的属性,我们在这里破例使用了
# 'from module import *'语句。使用 'from socket import *'，
# 我们就把 socket 模块里的所有属性都带到我们的命名空间里了，
# 这样能大幅减短我们的代码
tcpSock = socket(AF_INET, SOCK_STREAM)
服务端套接字函数
| 方法 | 用途 |
|---|---|
| s.bind() | 绑定（主机，端口号）到套接字 |
| s.listen() | 开始TCP监听 |
| s.accept() | 被动接受TCP客户的连接，（阻塞式）等待连接的到来 |
客户端套接字函数
| 方法 | 用途 |
|---|---|
| s.connect() | 主动初始化TCP服务器连接 |
| s.connect_ex() | connect()函数的扩展版本，出错时返回出错码，而不是抛出异常 |
公共用途的套接字函数
| 方法 | 用途 |
|---|---|
| s.recv() | 接收TCP数据 |
| s.send() | 发送TCP数据(send在待发送数据量大于己端缓存区剩余空间时,数据丢失,不会发完) |
| s.sendall() | 发送完整的TCP数据(本质就是循环调用send,sendall在待发送数据量大于己端缓存区剩余空间时,数据不丢失,循环调用send直到发完) |
| s.recvfrom() | 接收UDP数据 |
| s.sendto() | 发送UDP数据 |
| s.getpeername() | 连接到当前套接字的远端的地址 |
| s.getsockname() | 当前套接字的地址 |
| s.getsockopt() | 返回指定套接字的参数 |
| s.setsockopt() | 设置指定套接字的参数 |
| s.close() | 关闭套接字 |
面向锁的套接字方法
| 方法 | 用途 |
|---|---|
| s.setblocking() | 设置套接字的阻塞与非阻塞模式 |
| s.settimeout() | 设置阻塞套接字操作的超时时间 |
| s.gettimeout() | 得到阻塞套接字操作的超时时间 |
面向文件的套接字的函数
| 方法 | 用途 |
|---|---|
| s.fileno() | 套接字的文件描述符 |
| s.makefile() | 创建一个与该套接字相关的文件 |
基于TCP协议的套接字编程（简单）
- 可以通过
netstat - an | findstr 8080查看套接字状态
服务端
import socket
# 1. 买手机
# tcp称为流式协议,udp称为数据报协议SOCK_DGRAM
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# print(phone)
# 2.插入/绑定手机卡
# phone.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)
phone.bind(('127.0.0.1', 8081))
# 3. 开机
phone.listen(5) # 半连接池，限制的是请求数
# 4.等待电话连接
print('start...')
conn, client_addr = phone.accept() # （三次握手建立的双向连接，（客户端的ip，端口））
print(conn)
print(client_addr)
# 5. 通信：收/发消息
data = conn.recv(1024) # 最大接收的字节数
print('来自客户端的数据', data)
conn.send(data.upper())
# import time
# time.sleep(500)
# 6. 挂掉电话连接
conn.close()
# 7.关机
phone.close()
start...
客户端
import socket
# socket.AF
# 1. 买手机
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print(phone)
# 2. 拨电话
phone.connect(('127.0.0.1', 8081)) # 指定服务端IP和端口
# 3. 通信：发/收消息
phone.send('hello'.encode('utf8'))
# phone.send(bytes('hello',encoding='utf8'))
data = phone.recv(1024)
print(data)
# import time
# time.sleep(500)
# 4、关闭
phone.close()
基于TCP协议的套接字编程（循环）
服务端
import socket
# 1.买手机
phone = socket.socket(socket.AF_INET, sock.SOCK_STREAM)
# 2.绑定手机开卡
phone.bind(('127.0.0.1', 8080))
# 3.开机
phone.listen(5)
# 4.等待电话连接
print('start...')
while True:
conn, client_addr = phone.accept()
print('一个连接建立成功', client_addr)
while True:
try:
data = conn.recv(1024)
if len(data) == 0:
break
print('来自客户端数据', data)
conn.send(data.upper())
except ConnectionResetError: # 当前连接断开
break
conn.close()
phone.close()
客户端1
import socket
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
phone.connect(('127.0.0.1', 8080))
while True:
msg = input('请输入信息》》》').strip()
if len(msg) == 0:
continue
phone.send(msg.encode('utf8'))
data = phone.recv(1024)
print(data)
phone.close()
客户端2
import socket
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
phone.connect(('127.0.0.1', 8080))
while True:
msg = input('请输入信息》》》').strip()
if len(msg) == 0:
continue
phone.send(msg.encode('utf8'))
data = phone.recv(1024)
print(data)
phone.close()
地址占用问题
由于你的服务端仍然存在四次挥手的time_wait状态在占用地址（如果不懂，请深入研究1.tcp三次握手，四次挥手 2.syn洪水攻击 3.服务器高并发情况下会有大量的time_wait状态的优化方法）
方法一
# 加一条socket配置，重用IP和端口
phone = socket(AF_INET, SOCK_STREAM)
phone.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
phone.bind(('127.0.0.1', 8080))
方法二
发现系统存在大量TIME_WAIT状态的连接，通过调整linux内核参数解决，
vi /etc/sysctl.conf
编辑文件，加入以下内容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后执行 /sbin/sysctl -p 让参数生效。
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间
模拟ssh远程执行命令
服务端
from socket import *
import subprocess
server = socket(AF_INET, SOCK_STREAM)
server.bind(('127.0.0.1', 8080))
server.listen(5)
print('start...')
while True:
conn, client_addr = server.accept()
while True:
print('from client:', client_addr)
cmd = conn.recv(1024)
if len(cmd) == 0:
break
print('cmd:', cmd)
obj = subprocess.Popen(cmd.decode('utf8'), # 输入的cmd命令
shell=True, # 通过shell运行
stderr=subprocess.PIPE, # 把错误输出放入管道，以便打印
stdout=subprocess.PIPE) # 把正确输出放入管道，以便打印
stdout = obj.stdout.read() # 打印正确输出
stderr = obj.stderr.read() # 打印错误输出
conn.send(stdout)
conn.send(stderr)
conn.close()
server.close()
客户端
import socket
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect(('127.0.0.1', 8080))
while True:
data = input('please enter your data')
client.send(data.encode('utf8'))
data = client.recv(1024)
print(f'from server:{data}')
client.close()
输入dir命令，由于服务端发送字节少于1024字节，客户端可以接受。
输入tasklist命令，由于服务端发送字节多于1024字节，客户端只接受部分数据，并且当你再次输入dir命令的时候，客户端会接受dir命令的结果，但是会打印上一次的剩余未发送完的数据，这就是粘包问题。
粘包问题
什么是粘包
注意：只有TCP有粘包现象，UDP永远不会粘包
发送端可以是一K一K地发送数据，而接收端的应用程序可以两K两K地提走数据，当然也有可能一次提走3K或6K数据，或者一次只提走几个字节的数据，也就是说，应用程序所看到的数据是一个整体，或说是一个流（stream），一条消息有多少字节对应用程序是不可见的，因此TCP协议是面向流的协议，这也是容易出现粘包问题的原因。而UDP是面向消息的协议，每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据，这一点和TCP是很不同的。怎样定义消息呢？可以认为对方一次性write/send的数据为一个消息，需要明白的是当对方send一条信息的时候，无论底层怎样分段分片，TCP协议层会把构成整条消息的数据段排序完成后才呈现在内核缓冲区。
例如基于TCP的套接字客户端往服务端上传文件，发送时文件内容是按照一段一段的字节流发送的，在接收方看了，根本不知道该文件的字节流从何处开始，在何处结束。
所谓粘包问题主要还是因为接收方不知道消息之间的界限，不知道一次性提取多少字节的数据所造成的。
此外，发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一个TCP段。若连续几次需要send的数据都很少，通常TCP会根据优化算法把这些数据合成一个TCP段后一次发送出去，这样接收方就收到了粘包数据。
- TCP（transport control protocol，传输控制协议）是面向连接的，面向流的，提供高可靠性服务。收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
- UDP（user datagram protocol，用户数据报协议）是无连接的，面向消息的，提供高效率服务。不会使用块的合并优化算法，, 由于UDP支持的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样，对于接收端来说，就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。
- TCP是基于数据流的，于是收发的消息不能为空，这就需要在客户端和服务端都添加空消息的处理机制，防止程序卡住，而udp是基于数据报的，即便是你输入的是空内容（直接回车），那也不是空消息，udp协议会帮你封装上消息头，实验略
udp的recvfrom是阻塞的，一个recvfrom(x)必须对唯一一个sendinto(y),收完了x个字节的数据就算完成,若是y>x数据就丢失，这意味着udp根本不会粘包，但是会丢数据，不可靠
TCP的协议数据不会丢，没有收完包，下次接收，会继续上次继续接收，己端总是在收到ack时才会清除缓冲区内容。数据是可靠的，但是会粘包。
TCP发送数据的四种情况
假设客户端分别发送了两个数据包D1和D2给服务端，由于服务端一次读取到的字节数是不确定的，所以存在以下4种情况。
- 服务端分两次读取到了两个独立的数据包，分别是D1和D2，没有粘包和拆包；
- 服务器一次接收到了两个数据包，D1和D2粘合在一起，被称为TCP粘包；
- 服务端分两次读取到了两个数据包，第一次读取到了完整的D1包和D2包的部分内容，第二次读取到了D2包剩余内容，这被称之为TCP拆包；
- 服务端分两次读取到了两个数据包，第一次读取到了D1包的部分内容D1_1，第二次读取到了D1包的剩余内容D1_2和D2包的整包
特例：如果此时服务端TCP接收滑窗非常小，而数据包D1和D2比较大，很有可能会发生第五种可能，即服务端分多次才能将D1和D2包接收完全，期间发生多次拆包。
粘包的两种情况
1. 发送端需要等缓冲区满才发送出去，造成粘包（发送数据时间间隔很短，数据很小，会合到一起，产生粘包）
服务端
# _*_coding:utf-8_*_
__author__ = 'tom'
from socket import *
ip_port = ('127.0.0.1', 8080)
TCP_socket_server = socket(AF_INET, SOCK_STREAM)
TCP_socket_server.bind(ip_port)
TCP_socket_server.listen(5)
conn, addr = TCP_socket_server.accept()
data1 = conn.recv(10)
data2 = conn.recv(10)
print('--->', data1.decode('utf8'))
print('--->', data2.decode('utf8'))
conn.close()
客户端
# _*_coding:utf-8_*_
__author__ = 'tom'
import socket
BUFSIZE = 1024
ip_port = ('127.0.0.1', 8080)
s = socket.socket(socket.AF_INET, socket.SSOCK_STREAM)
res = s.connect_ex(ip_port)
s.send('hello'.encode('utf8'))
s.send('world'.encode('utf8'))
2 . 接收方不及时接收缓冲区的包，造成多个包接收（客户端发送了一段数据，服务端只接收了一小部分，服务端下次再收的时候还是从缓冲区拿上次遗留的数据，产生粘包）
# _*_coding:utf-8_*_
__author__ = 'tom'
from socket import *
ip_port = ('127.0.0.1', 8080)
TCP_socket_server = socket(AF_INET, SOCK_STREAM)
TCP_socket_server.bind(ip_port)
TCP_socket_server.listen(5)
conn, addr = TCP_socket_server.accept()
data1 = conn.recv(2) # 一次没有收完整
data2 = conn.recv(10) # 下次收的时候,会先取旧的数据,然后取新的
print('----->', data1.decode('utf-8'))
print('----->', data2.decode('utf-8'))
conn.close()
客户端
# _*_coding:utf-8_*_
__author__ = 'tom'
import socket
BUFSIZE = 1024
ip_port = ('127.0.0.1', 8080)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
res = s.connect_ex(ip_port)
s.send('hello'.encode('utf-8'))
补充问题一：为何TCP是可靠传输，UDP是不可靠传输
- TCP在数据传输时，发送端先把数据发送到自己的缓存中，然后协议控制将缓存中的数据发往对端，对端返回一个ack=1，发送端则清理缓存中的数据，对端返回ack=0，则重新发送数据，所以TCP是可靠的
- UDP发送数据，对端是不会返回确认信息的，因此不可靠
补充问题二：send（字节流）和recv（1024）及sendall
-
recv里指定的1024意思是从缓存里一次拿出1024个字节的数据
-
send的字节流是先放入己端缓存，然后由协议控制将缓存内容发往对端，如果待发送的字节流大小大于缓存剩余空间，那么数据丢失，用sendall就会循环调用send，数据不会丢失。
解决粘包问题
解决粘包问题（low版）
问题的根源在于，接收端不知道发送端将要传送的字节流的长度，所以解决粘包的方法就是围绕，如何让发送端在发送数据前，将自己将要发送的字节流大小让接收端知晓，然后接收端来一个死循环就收完所有数据。
服务端
import socket
import subprocess
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind('127.0.0.1', 8000)
server.listen(5)
while True:
conn, addr = server.accept()
print('start...')
while True:
cmd = conn.recv(1024)
print(f'cmd:{cmd}')
obj = subprocess.Popen(cmd.decode('utf8'),
shell=True,
stderr=subprocess.PIPE,
stdout=subprocess.PIPE)
stdout = obj.stdout.read()
if stdout:
ret = stdout
else:
stderr = obj.stderr.read()
ret = stderr
ret_len = len(ret)
conn.send(str(ret_len).encode('utf8'))
data = conn.recv(1024).decode('utf8')
if data == 'recv_ready':
conn.sendall(ret)
conn.close()
server.close()
客户端
import socket
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect(('127.0.0.1', 8080))
while True:
msg = input('please enter your cmd you want>>>').strip
if len(msg) == 0:
continue
client.send(msg.ecode('utf8'))
length = int(client.recv(1024))
client.send('recv_ready'.encode('utf8'))
send_size = 0
recv_size = 0
data = b''
while recv_size < length:
data = client.recv(1024)
recv_size += len(data)
print(data.dacode('utf8'))
为何low
程序的运行速度远快于网络传输速度，所以在发送一段字节前，先用send去发送该字节流长度，这种方式会放大网络延迟带来的性能损耗
补充struct模块
import struct
import json
# 'i'是格式
try:
obj = struct.pack('i', 12223432)
except Exception as e:
print(e)
obj = struct.pack('i', 12)
print(obj, len(obj))
b'\xc8\x83\xba\x00' 4
res = struct.unpack('i', obj)
print(res[0])
12223432
解决粘包问题
解决粘包问题的核心就是：为字节流加上自定义固定长度报头，报头中包含字节流长度，然后一次send到对端，对端在接收时，先从缓存中取出定长的报头，然后再取真实数据。
使用struct模块创建报头
import json
import struct
header_dict = {
'filename': 'a.txt',
'total_size': 1111111111111111111111111111111111222222224444444442,
'hash': 'aefsg23rafarafa'
}
header_json = json.dumps(header_dict)
header_bytes = header_json.encode('utf8')
print(len(header_bytes))
# 'i'是格式
obj = struct.pack('i', len(header_bytes))
print(obj, len(obj))
116
b't\x00\x00\x00' 4
res = struct.unpack('i', obj)
print(res[0])
116
服务端
from socket import *
import subprocess
import struct
import json
server = socket(AF_INET, SOCK_STREAM)
server.bind(('127.0.0.1', 8000))
server.listen(5)
print('start...')
while True:
conn, client_addr = server.accept()
print(conn, client_addr)
while True:
cmd = conn.recv(1024)
obj = subprocess.Popen(cmd.decode('utf8'),
shell=True,
stderr=subprocess.PIPE,
stdout=subprocess.PIPE)
stderr = obj.stderr.read()
stdout = obj.stdout.read()
# 制作报头
header_dict = {
'filename': 'a.txt',
'total_size': len(stdout)+len(stderr),
'hash': 'xasf123213123'
}
header_json = json.dumps(header_dict)
header_bytes = header_json.encode('utf8')
# 1. 先把报头的长度len(header_bytes)打包成4个bytes，然后发送
conn.send(struct.pack('i', len(header_bytes)))
# 2. 发送报头
conn.send(header_bytes)
# 3. 发送真实的数据
conn.send(stdout)
conn.send(stderr)
conn.close()
server.close()
客户端
from socket import *
import json
import struct
client = socket(AF_INET, SOCK_STREAM)
client.connect(('127.0.0.1', 8000))
while True:
cmd = input('please enter your cmd you want>>>').strip()
if len(cmd) == 0:
continue
client.send(cmd.encode('utf8'))
header_len = struct.unpack('i', client.recv(4))[0]
header_bytes = client.recv(header_len)
header_json = header_bytes.decode('utf8')
header_dict = json.loads(header_json)
total_size = header_dict['total_size']
recv_size = 0
res = b''
while recv_size < total_size:
data = client.recv(1024)
res += data
recv_size += len(data)
print(res.decode('utf8'))
client.close()
TCP协议粘包问题分析
1.nagle算法规定，TCP协议会将数据量较小、时间间隔短的数据合并为一条发送给客户端
服务端
from socket import *
server = socket(AF_INET, SOCK_STREAM)
server.bind(('127.0.0.1', 8080))
server.listen(5)
conn, addr = server.accept()
# 正确做法，客户端制作报头
# res1 = conn.recv(5)
# print('第一次；', res1)
# res2 = conn.recv(5)
# print('第二次；', res2)
# res3 = conn.recv(4)
# print('第三次；', res3)
# low方法+客户端的睡眠
res1 = conn.recv(1024)
print(f'第一次：{res1}')
res2 = conn.recv(1024)
print(f'第二次：{res2}')
res3 = conn.recv(1024)
print(f'第三次：{res3}')
客户端
from socket import *
import time
client = socket(AF_INET, SOCK_STREAM)
client.connect(('127.0.0.1', 8080))
client.send(b'hello')
client.send(b'world')
client.send(b'tom')
# 服务端收到b'helloworldnick'
client.send(b'hello')
time.sleep(0.2)
# 服务端收到b'hello'
client.send(b'world')
time.sleep(0.2)
# 服务端收到b'world'
client.send(b'tom')
# 服务端收到b'tom'
2.接收方不及时接收缓冲区的包，造成多个包接收（客户端发送了一段数据，服务端只接收了一小部分，服务端下次再收的时候还是从缓冲区拿上次遗留的数据，产生粘包）
服务端
# _*_coding:utf-8_*_
__author__ = 'nickchen121'
from socket import *
ip_port = ('127.0.0.1', 8080)
TCP_socket_server = socket(AF_INET, SOCK_STREAM)
TCP_socket_server.bind(ip_port)
TCP_socket_server.listen(5)
conn, addr = TCP_socket_server.accept()
data1 = conn.recv(2) # 一次没有收完整
data2 = conn.recv(10) # 下次收的时候,会先取旧的数据,然后取新的
print('----->', data1.decode('utf-8'))
print('----->', data2.decode('utf-8'))
conn.close()
客户端
# _*_coding:utf-8_*_
__author__ = 'tom'
import socket
BUFSIZE = 1024
ip_port = ('127.0.0.1', 8080)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
res = s.connect_ex(ip_port)
s.send('hello'.encode('utf8'))
基于UDP协议的套接字编程
UDP套接字简单示例
服务端
import socket
server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # 数据报协议UDP
server.bind(('127.0.0.1', 8080))
while True:
data, client_addr = server.recvfrom(1024)
print('--->', data, client_addr)
server.sendto(data.upper(), client_addr)
server.close()
客户端
import socket
client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
while True:
msg = input('--->').strip()
client.sendto(msg.encode('utf8'), ('127.0.0.1', 8080))
data, server_addr = client.recvfrom(1024)
print(data)
client.close()
-
UDP是无链接的，先启动哪一端都不会报错
-
UDP协议是数据协报协议，发空的时候也会自带报头，因此客户端输入空，服务端也能收到
UDP套接字无粘包问题
服务端
import socket
server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
server.bind(('127.0.0.1', 8080))
data, client_addr = server.recvfrom(1024)
print('第一次：', client_addr, data)
data, client_addr = server.recvfrom(1024)
print('第二次：', client_addr, data)
server.close()
客户端
import socket
client = socket.socket(socket.AF_INET, socket.DGRAM)
client.sendto('hello'.encode('utf8'), ('127.0.0.1', 8080))
client.sendto('world'.encode('utf8'), ('127.0.0.1', 8080))
client.close()
-
UDP协议一般不用于传输大数据
-
UDP套接字虽然没有粘包问题，但是不能替代TCP套接字，因为UDP协议有一个缺陷：如果数据发送的中途，数据丢失，则数据就丢失了，而TCP协议则不会有这种缺陷，因此一般UDP套接字用户无关紧要的数据发送，例如QQ聊天。
QQ聊天
- 由于UDP无链接，所以可以同时多个客户端去跟服务端通信
服务端
# _*_coding:utf-8_*_
__author__ = 'nick'
import socket
ip_port = ('127.0.0.1', 8081)
UDP_server_sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # 买手机
UDP_server_sock.bind(ip_port)
while True:
qq_msg, addr = UDP_server_sock.recvfrom(1024)
print('来自[%s:%s]的一条消息:\033[1;44m%s\033[0m' %
(addr[0], addr[1], qq_msg.decode('utf-8')))
back_msg = input('回复消息: ').strip()
UDP_server_sock.sendto(back_msg.encode('utf-8'), addr)
客户端1
# _*_coding:utf-8_*_
__author__ = 'nick'
import socket
BUFSIZE = 1024
UDP_client_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
qq_name_dic = {
'狗哥alex': ('127.0.0.1', 8081),
'瞎驴': ('127.0.0.1', 8081),
'一棵树': ('127.0.0.1', 8081),
'武大郎': ('127.0.0.1', 8081),
}
while True:
qq_name = input('请选择聊天对象: ').strip()
while True:
msg = input('请输入消息,回车发送: ').strip()
if msg == 'quit':
break
if not msg or not qq_name or qq_name not in qq_name_dic:
continue
UDP_client_socket.sendto(msg.encode('utf-8'), qq_name_dic[qq_name])
back_msg, addr = UDP_client_socket.recvfrom(BUFSIZE)
print('来自[%s:%s]的一条消息:\033[1;44m%s\033[0m' %
(addr[0], addr[1], back_msg.decode('utf-8')))
UDP_client_socket.close()
客户端2
# _*_coding:utf-8_*_
__author__ = 'nick'
import socket
BUFSIZE = 1024
UDP_client_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
qq_name_dic = {
'狗哥alex': ('127.0.0.1', 8081),
'瞎驴': ('127.0.0.1', 8081),
'一棵树': ('127.0.0.1', 8081),
'武大郎': ('127.0.0.1', 8081),
}
while True:
qq_name = input('请选择聊天对象: ').strip()
while True:
msg = input('请输入消息,回车发送: ').strip()
if msg == 'quit':
break
if not msg or not qq_name or qq_name not in qq_name_dic:
continue
UDP_client_socket.sendto(msg.encode('utf-8'), qq_name_dic[qq_name])
back_msg, addr = UDP_client_socket.recvfrom(BUFSIZE)
print('来自[%s:%s]的一条消息:\033[1;44m%s\033[0m' %
(addr[0], addr[1], back_msg.decode('utf-8')))
UDP_client_socket.close()
基于socketserver实现并发的socket
基于TCP协议
基于tcp的套接字，关键就是两个循环，一个链接循环，一个通信循环
socketserver模块中分两大类：server类（解决链接问题）和request类（解决通信问题）
服务端
import socketserver
class MyHandler(socketserver.BaseRequsetHandler):
def handle(self):
# 通信循环
while True:
try:
data = self.request.recv(1024)
if len(data) == 0:
break
self.request.send(data.upper())
except ConnectionResetError:
break
if __name__ == '__main__':
s = socketserver.ThreadingTCPServer(
('1217.0.0.1', 8080), MyHandler, bind_and_activate=True)
s.server_forever() # 代表链接循环
# 循环建立连接，每建立一个连接就会启动一个线程（服务员）+调用Myhanlder类产生一个对象，调用该对象下的handle方法，专门与刚刚建立好的连接做通信循环
客户端
import socket
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
phone.connect(('127.0.0.1', 8080)) # 指定服务端IP和端口
while True:
msg = 'client111111'
if len(msg) == 0:
continue
phone.send(msg.encode('utf8'))
data = phone.recv(1024)
print(data)
phone.close()
客户端1
import socket
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
phone.connect(('127.0.0.1', 8080)) # 指定服务端IP和端口
while True:
msg = 'client22222'
if len(msg) == 0:
continue
phone.send(msg.encode('utf8'))
data = phone.recv(1024)
print(data)
phone.close()
基于UDP协议
服务端
import socketserver
calss MyHandler(socketserver.BaseRequestHandler):
def handle(self):
print(self.client_address)
print(self.request)
data = self.request[0]
print('客户消息'，data)
self.request[1].sendto(data.upper(), self.client_address)
if __name__ == '__main__':
s = socketserver.TheadingUDPServer(('127.0.0.1', 8080), MyHandler)
s.server_forever()
客户端
import socket
client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
while True:
msg = 'client1111'
client.sendto(msg.encode('utf8'), ('127.0.0.1', 8080))
data, server_addr = client.recvfrom(1024)
print(data)
client.close()
客户端1
import socket
client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # 数据报协议-》udp
while True:
# msg=input('>>: ').strip() #msg=''
msg = 'client2222'
client.sendto(msg.encode('utf-8'), ('127.0.0.1', 8080))
data, server_addr = client.recvfrom(1024)
print(data)
client.close()
socketserver源码分析
ftpserver = socketserver.ThreadingTCPServer(('127.0.0.1', 8080), FtpServer)
ftpserver.serve_forever()
-
查找属性的顺序：ThreadingTCPServer->ThreadingMixIn->TCPServer->BaseServer
-
实例化得到ftpserver，先找类ThreadingTCPServer的__init__，在TCPServer中找到，进而执行server_bind，server_active
-
找ftpserver下的serve_forever，在BaseServer中找到，进而执行self._handle_request_noblock()，该方法同样是在BaseServer中
-
执行self._handle_request_noblock()进而执行request， client_address = self.get_request()（就是TCPServer中的self.socket.accept()），然后执行self.process_request(request， client_address)
-
在ThreadingMixIn中找到process_request，开启多线程应对并发，进而执行process_request_thread，执行self.finish_request(request， client_address)
-
上述四部分完成了链接循环，本部分开始进入处理通讯部分，在BaseServer中找到finish_request，触发我们自己定义的类的实例化，去找__init__方法，而我们自己定义的类没有该方法，则去它的父类也就是BaseRequestHandler中找....
源码总结
- 基于TCP的socketserver我们定义的类中的
* self.server即套接字对象
* self.request即一个链接
* self.client_address即客户端地址
- 基于UDP的socketserver我们自己定义的类中的
* self.request是一个元组（第一个元素是客户端发来的数据，第二部分是服务端的udp套接字对象），如(b'adsf', <socket.socket fd=200, family=AddressFamily.AF_INET, type=SocketKind.SOCK_DGRAM, proto=0, laddr=('127.0.0.1', 8080)>)
* self.client_address即客户端地址
