网络编程:
1. 网络基础
- MAC地址
- IP(网络之间互连的协议)
网络之间互连的协议(IP)是Internet Protocol的外语缩写, [1] 中文缩写为“网协”.
网络之间互连的协议也就是为计算机网络相互连接进行通信而设计的协议。在因特网中,它是能使连接到网上的所有计算机网络实现相互通信的一套规则,
规定了计算机在因特网上进行通信时应当遵守的规则。任何厂家生产的计算机系统,只要遵守IP协议就可以与因特网互连互通。
IP地址具有唯一性,根据用户性质的不同,可以分为5类。另外,IP还有进入防护,知识产权,指针寄存器等含义。
- 子网掩码
- 网关
网关(Gateway)又称网间连接器、协议转换器。
网关在网络层以上实现网络互连,是最复杂的网络互连设备,仅用于两个高层协议不同的网络互连。网关既可以用于广域网互连,也可以用于局域网互连。
网关是一种充当转换重任的计算机系统或设备。使用在不同的通信协议、数据格式或语言,甚至体系结构完全不同的两种系统之间,网关是一个翻译器。
与网桥只是简单地传达信息不同,网关对收到的信息要重新打包,以适应目的系统的需求。同层--应用层。
- DHCP服务
- 路由器
- 交换机
交换机(Switch)意为“开关”是一种用于电(光)信号转发的网络设备。
它可以为接入交换机的任意两个网络节点提供独享的电信号通路。最常见的交换机是以太网交换机。其他常见的还有电话语音交换机、光纤交换机等。
- 广播/单播
单播:
单播(unicast)是指封包在计算机网络的传输中,目的地址为单一目标的一种传输方式。
每次只有两个实体相互通信,发送端和接收端都是唯一确定的。它是现今网络应用最为广泛,通常所使用的网络协议或服务大多采用单播传输,例如一切基于TCP的协议。
单播地址
在IPv4网络中,0.0.0.0到223.255.255.255属于单播地址。
单播优点
-
服务器及时响应客户机的请求
-
服务器针对每个客户不通的请求发送不通的数据,容易实现个性化服务。
-
单播缺点:
-
服务器针对每个客户机发送数据流,服务器流量=客户机数量×客户机流量;在客户数量大、每个客户机流量大的流媒体应用中服务器不堪重负。
-
现有的网络带宽是金字塔结构,城际省际主干带宽仅仅相当于其所有用户带宽之和的5%。如果全部使用单播协议,将造成网络主干不堪重负。现在的P2P应用就已经使主干经常阻塞,只要有5%的客户在全速使用网络,其他人就不要玩了。而将主干扩展20倍几乎是不可能。
-
广播:
广播(broadcast)是指封包在计算机网络中传输时,目的地址为网络中所有设备的一种传输方式。
实际上,这里所说的“所有设备”也是限定在一个范围之中,称为“广播域”。
并非所有的计算机网络都支持广播,例如X.25网络和帧中继都不支持广播,而且也没有在“整个互联网范围中”的广播。
IPv6亦不支持广播,广播相应的功能由多播代替。
通常,广播都是限制在局域网中的,比如以太网或令牌环网络。
因为广播在局域网中造成的影响远比在广域网中小得多。
广播地址:
以太网和IPv4网都用全1的地址表示广播,分别是ff:ff:ff:ff:ff:ff和255.255.255.255。
广播优点:
-
网络设备简单,维护简单,布网成本低廉 。
-
由于服务器不用向每个客户机单独发送数据,所以服务器流量负载极低。
-
广播缺点:
-
无法针对每个客户的要求和时间及时提供个性化服务。
-
网络允许服务器提供数据的带宽有限,客户端的最大带宽=服务总带宽。例如有线电视的客户端的线路支持100个频道(如果采用数字压缩技术,理论上可以提供500个频道),即使服务商有更大的财力配置更多的发送设备、改成光纤主干,也无法超过此极限。也就是说无法向众多客户提供更多样化、更加个性化的服务。
-
广播禁止在Internet宽带网上传输。
-
- arp协议(地址解析协议)
地址解析协议,即ARP(Address Resolution Protocol),是根据IP地址获取物理地址的一个TCP/IP协议。
主机发送信息时将包含目标IP地址的ARP请求广播到网络上的所有主机,并接收返回消息,以此确定目标的物理地址;
收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间,下次请求时直接查询ARP缓存以节约资源。
地址解析协议是建立在网络中各个主机互相信任的基础上的,网络上的主机可以自主发送ARP应答消息,
其他主机收到应答报文时不会检测该报文的真实性就会将其记入本机ARP缓存;由此攻击者就可以向某一主机发送伪ARP应答报文,
使其发送的信息无法到达预期的主机或到达错误的主机,这就构成了一个ARP欺骗。ARP命令可用于查询本机ARP缓存中IP地址和MAC地址的对应关系、
添加或删除静态对应关系等。相关协议有RARP、代理ARP。NDP用于在IPv6中代替地址解析协议。
- DNS(域名系统)
DNS(Domain Name System,域名系统),万维网上作为域名和IP地址相互映射的一个分布式数据库,
能够使用户更方便的访问互联网,而不用去记住能够被机器直接读取的IP数串。
通过域名,最终得到该域名对应的IP地址的过程叫做域名解析(或主机名解析)。
DNS协议运行在UDP协议之上,使用端口号53。在RFC文档中RFC 2181对DNS有规范说明,
RFC 2136对DNS的动态更新进行说明,RFC 2308对DNS查询的反向缓存进行说明。
2. OSI 7层模型
开放系统互连参考模型 (Open System Interconnect 简称OSI)是国际标准化组织(ISO)和国际电报电话咨询委员会(CCITT)联合制定的开放系统互连参考模型,为开放式互连信息系统提供了一种功能结构的框架。
它从低到高分别是:
- 物理层
提供为建立、维护和拆除物理链路所需要的机械的、电气的、功能的和规程的特性;有关的物理链路上传输非结构的位流以及故障检测指示。
- 数据链路层
在网络层实体间提供数据发送和接收的功能和过程;提供数据链路的流控。
- 网络层
控制分组传送系统的操作、路由选择、拥护控制、网络互连等功能,它的作用是将具体的物理传送对高层透明。
- 传输层
提供建立、维护和拆除传送连接的功能;选择网络层提供最合适的服务;在系统之间提供可靠的透明的数据传送,提供端到端的错误恢复和流量控制。
- 会话层
提供两进程之间建立、维护和结束会话连接的功能;提供交互会话的管理功能,如三种数据流方向的控制,即一路交互、两路交替和两路同时会话模式 。
- 表示层
代表应用进程协商数据表示;完成数据转换、格式化和文本压缩。
- 应用层
提供OSI用户服务,例如事务处理程序、文件传送协议和网络管理等。
3. 三次握手四次挥手
4. BS和CS架构?
客户端:cs架构 , client ==> server
浏览器:bs架构 , browser ==> server
5. socket基本代码
服务端:
import socket # 创建服务端socket对象 server = socket.socket() #绑定IP和端口 server.bind(('127.0.0.1',8008)) #后面可以再等五个人 server.listen(5) #等待客户端来连接,如果没人来就傻傻的等待 #conn是客户端和服务端连接的对象, # 服务端以后要通过该对象进行收发数据 #addr是客户端的地址信息 conn,addr = server.accept() #阻塞 #通过对象去获取 #1024表示,服务端通过媒介获取数据时,一次性最多那1024字节 data = conn.recv(1024) print(data) #服务端通过连接对象给客户端回复了一个消息 conn.send(b'stop') #与客户端断开连接 conn.close() #关闭服务端的服务 server.close()
客户端:
import socket client = socket.socket() #向服务端发起连接请求 #阻塞,去练结知道连接成功后才会往下走 client.connect(('192.168.13.155',8000)) #连上服务端后,向服务端发消息 client.send(b'hahahahahah是谁呢') #等待服务端回消息 data = client.recv(1024) print(data) #关闭与服务器的连接 client.close()
6. 黏包
一、TCP黏包问题
TCP黏包问题是因为发送方把若干数据发送,接收方收到数据时候黏在一包,从接受缓冲区来看,后一包的数据黏在前一包的尾部。
二、黏包出现的原因
TCP黏包问题主要出现在两个方面
(1)发送方问题
首先TCP会默认使用Nagle算法,Nagle算法主要做两件事。
第一:上一包分组得到确认,才会发送下一分组。
第二:收集多个小组,在一个确认到来时一起发送。
由此可见Nagle算法会使得数据在发送方造成黏包问题 。
(2)接收方问题
TCP接收方接收到分组的时候,并不会立刻提交到应用层处理,收到的数据放在接收缓存里面,然后应用程序会主动从接受缓存里读取接收的分组,这样以来,
如果TCP接收分组的速度大于应用读取分组的速度,多个包的数据会存至缓存区里面,应用读取数据就可能会产生黏包问题。
三、什么时候处理黏包问题
(1)如果每次利用TCP发送数据,就与对方建立连接,然后发送完数据就关闭连接这样就不会出现黏包问题(大家都知道只发送一个数据包)
(2)如果发送的数据无结构,比如文件的传输,只要发送方一直发送,接收方只管接收到储存的数据,此时也不用考虑黏包问题。
(3)如果在连接的一段时间内发送的数据毫无关系,我们就要考虑黏包问题了。
比如:你要发送一段话
I love you.
I want play.
如果产生了黏包问题,接收方可能会傻眼,你让我干啥?所以一般会在数据前加一个长度之类的包,确保接收。
四、处理黏包现象
(1)发送方
发送方产生黏包问题的主要原因在于Nagle算法,我们可以通过关闭Nagle算法来解决,使用TCP_NODELAY选项来关闭Nagle算法。
(2)接收方
由于TCP没有处理接收方黏包现象的机制,我们只能在应用层进行处理。
(3)应用层处理
解决方法就是循环处理:应用程序在处理从缓存读来的分组时,读完一条数据时,就应该循环读下一条数据,直到所有的数据都被处理;但是如何判断每条数据的长度呢?
两种途径:
1)格式化数据:每条数据有固定的格式(开始符、结束符),这种方法简单易行,但选择开始符和结束符的时候一定要注意每条数据的内部一定不能出现开始符或结束符。
2)发送长度:发送每条数据的时候,将数据的长度一并发送,比如可以选择每条数据的前4位是数据的长度,应用层处理时可以根据长度来判断每条数据的开始和结束。
8. 协议
自定义协议:{'code':10001,data:{...}}
Http协议:GET /s?wd=alex HTTP/1.0\r\nhost:www.baidu.com\r\n\r\n