面试题之NETWORK

请简述TCPUDP的区别

TCPUDPOSI模型中的传输层中的协议。
TCP提供面向连接的可靠的通信传输,而UDP则是无连接的数据报传输。
两者的区别大致如下:TCP面向连接,UDP是无连接的。即发送数据前不需要建立链接TCP提供可靠的服务(数据传输),UDP无法保证。
TCP面向字节流,UDP是面向报文的
TCP数据传输慢,UDP数据传输快
TCP对数据进行分段,数据长度没有限制。UDP不对报文进行分段,所有会限制报文长度。
TCP的话,传输层负担大,应用层负担小。UDP相反。因为UDP把活都推给应用层去干了。
TCP按序,可靠,在数据传输之前有一个协调过程,所以TCP传东西慢。UDP不按序,不可靠。

请简单说一下你了解的端口及对应的服务

在这里插入图片描述
3389 远程控制

说一说TCP的三次握手与四次挥手

TCP/IP协议中,TCP协议提供可靠的连接服务,连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。

在这里插入图片描述
在这里插入图片描述
总之就是,客户端发起连接请求,SYN=1 seq = x 进入到SYN_SEND状态。
服务器收到连接请求,ACK=x+1 SYN=1 seq = y 进入到SYN_RECV状态。
客户端发送ACK = y+1 双方都进入ESTABLISHED状态。这样就完成了3次握手。

为什么要是3次握手?
因为3次握手才能建立起双向的连接,不至于耗费资源。

什么是DDoS:
DDoS就是客户端向服务器发送请求,服务器返回SYN/ACK 但是客户端不会返回ACK
服务器就在那一直等着客户端的ACK。然后就被耗费资源了。

如何处理DDoS
限制同时打开SYN半链接的数目
缩短SYN半链接的Time out 时间
关闭不必要的服务

白话版三次握手:
我要和你建立链接,你真的要和我建立链接么,我真的要和你建立链接,成功
四次挥手:
我要和你断开链接;好的,断吧;我也要和你断开链接;好的,断吧
客户端发起释放链接请求 FIN=1 ACK=1 seq=u u是数据的最后一个字节的序号+1
服务器返回ACK(u+1)并释放FIN=0
服务器端也向客户端发出连接释放请求FIN=1 seq = v ACK(u+1)
客户端发送ACK(v+1) 释放所有资源,关闭连接。服务器收到ACK(v+1)也释放所有资源关闭连接。

IP地址分为哪几类?简单说一下各个分类以及分段

在这里插入图片描述
IP地址是用.来分段的。分成了ABCD段。

AAA.BBB.CCC.DDD

通常渗透测试所说的C段,就是这个意思。
IPv6 – 采用128bit,首部固定部分为40字节。

在浏览器中输入网址之后执行会发生什么?

  • 查找域名对应的IP地址。这一步会依次查找浏览器缓存,系统缓存,路由器缓存,ISPDNS缓存,根域名服务器
  • 浏览器向IP对应的web服务器发送一个HTTP请求
  • 服务器响应请求,发回网页内容
  • 浏览器解析网页内容
    在这里插入图片描述

简单解释一些ARP协议的工作过程

什么叫ARP协议?
简介:
ARP协议是根据IP地址获取MAC地址的一个协议。主机发送信息时将包含目标IP地址的ARP请求广播到网络上的所有主机,并接收返回消息,以此确定目标的物理地址;收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间,下次请求时直接查询ARP缓存以节约资源。
原理:
OSI模型把网络工作分为七层,IP地址在OSI模型的第三层,MAC地址在第二层,彼此不直接打交道。在通过以太网发送IP数据包时,需要先封装第三层(32位IP地址)、第二层(48位MAC地址)的报头,但由于发送时只知道目标IP地址,不知道其MAC地址,又不能跨第二、三层,所以需要使用地址解析协议。使用地址解析协议,可根据网络层IP数据包包头中的IP地址信息解析出目标硬件地址(MAC地址)信息,以保证通信的顺利进行。
具体的工作过程:
主机A的IP地址为192.168.1.1,MAC地址为0A-11-22-33-44-01;
主机B的IP地址为192.168.1.2,MAC地址为0A-11-22-33-44-02;
当主机A要与主机B通信时,地址解析协议可以将主机B的IP地址(192.168.1.2)解析成主机B的MAC地址。
以下为工作流程:
第1步:根据主机A上的路由表内容,IP确定用于访问主机B的转发IP地址是192.168.1.2。然后A主机在自己的本地ARP缓存中检查主机B的匹配MAC地址。
第2步:如果主机A在ARP缓存中没有找到映射,它将询问192.168.1.2的硬件地址,从而将ARP请求帧广播到本地网络上的所有主机。源主机A的IP地址和MAC地址都包括在ARP请求中。本地网络上的每台主机都接收到ARP请求并且检查是否与自己的IP地址匹配。如果主机发现请求的IP地址与自己的IP地址不匹配,它将丢弃ARP请求。
第3步:主机B确定ARP请求中的IP地址与自己的IP地址匹配,则将主机A的IP地址和MAC地址映射添加到本地ARP缓存中。
第4步:主机B将包含其MAC地址的ARP回复消息直接发送回主机A。
第5步:当主机A收到从主机B发来的ARP回复消息时,会用主机B的IP和MAC地址映射更新ARP缓存。本机缓存是有生存期的,生存期结束后,将再次重复上面的过程。主机B的MAC地址一旦确定,主机A就能向主机B发送IP通信了。

既然IP地址已经标识了网络上唯一的一台主机,那么为什么要MAC地址呢?
这牵扯到了分层问题。因为分层,所以还要知道对方的MAC地址。怎么能知道对方的MAC?要使用ARP解析。通过IP地址来知道对方的MAC。
大白话版的工作流程:
吼一嗓子,我是BJFU的vth,要找SDUT的人,赶紧把人交出来!
SDUT的nwl一听,卧槽,BJFU的vth找我,赶紧记到小本本上。(ARP缓存)
SDUT把nwl交给了BJFU的vth,然后vth就明白了,原来我要发信给SDUT的nwl啊,好的,我要记到小本本上(ARP缓存)。说干就干。开始发送。
再大白话说明原理:
通信要知道对面的IP和MAC,一开始不可能知道MAC的,怎么办?先发个包探探路,吼一嗓子,找明白MAC是哪个了再正式发送该发的东西。
在这里插入图片描述

说一说OSI七层模型

在这里插入图片描述
物理层:传二进制流
数据链路层:封装成分组
网络层:路由,分组转发
传输层:进程间通信
会话层:进程间会话
表示层:编解码
应用层:常用的一些WEB应用

说一说TCP/IP四层模型

为什么要有TCP/IP四层?
因为OSI7层划分的太过细致,而且只是定义了功能,别的啥都没干。是个假模型。
而且OSI7层不适用于现实。因为不同类型网络不可能定义相同的物理层和链路层。
所以TCP/IP干了一件比较聪明的事儿,它把原来物理层和数据链路层给搞成了一个网络接口层,向下提供接口。同一网络的结点帧传输自己去解决。
网际层是连接在不同类型的网络上两个终端之间的通信过程。
传输层增加了差错控制和拥塞控制。
应用层包含了OSI的上三层。
在这里插入图片描述

HTTP 协议包括哪些请求?

GET:对服务器资源的简单请求
POST:用于发送包含用户提交数据的请求
------------以及------------
HEAD:类似于GET请求,不过返回的响应中没有具体内容,用于获取报头
PUT:传说中请求文档的一个版本
DELETE:发出一个删除指定文档的请求
TRACE:发送一个请求副本,以跟踪其处理进程
OPTIONS:返回所有可用的方法,检查服务器支持哪些方法
CONNECT:用于ssl隧道的基于代理的请求
当然啦。最常用的还是GETPOST

简述HTTP中GET和POST的区别

从原理性看:根据HTTP规范,GET用于信息获取,而且应该是安全的
根据HTTP规范,POST请求表示可能修改服务器上资源的请求
从表面上看:
GET请求的数据会附在URL后面,POST的数据放在HTTP包体
POST安全性比GET安全性高

URI与URL

所有的URL都是URI 反之不行。
URL是统一资源定位符,URI是统一资源标识符。

192.168.22.11/24请问IP后面跟的/24是什么意思?

24表示了掩码用二进制表示时1的位数
也就是说,它的掩码是255.255.255.0
子网掩码前面的1表示的是网络位,后面的0是主机位。
子网掩码的作用就是指明了IP地址中作为网络号的二进制数。
IP地址分为分类编址和无分类编址,分类编址中,ABC三类AP地址中的网络号和主机号是固定的,IP地址浪费很严重。
解决办法:应用无分类编址。无分类编址允许随意改变IP地址中网络号和主机号位数。

HTTP与HTTPS的区别:

HTTP是超文本传输协议,HTTPS是安全超文本传输协议。从名字就能看出来HTTPS更加安全。
HTTP+加密+认证+完整性保护=HTTPS
HTTPS是身披SSL外壳的HTTP
HTTPS并非是应用层的一种新协议,只是HTTP通信接口部分用SSL和TLS协议代替而已。
通常情况下,HTTP直接与TCP进行通信。当使用SSL时,则HTTP先和SSL通信,再由SSL和TCP通信。SSL是独立的一个协议,其他运行于应用层的协议比如SMTP和TELNET等协议都可以配合SSL协议使用。
HTTP用80号端口,HTTPS用443端口
HTTPS通信更耗资源(为了安全就得牺牲速度。就像过地铁安检一样的道理)
开销:HTTPS通信需要证书,证书一般需要向认证机构购买。很费钱的。
HTTPS的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

对称加密与非对称加密:
对称加密:是指加密与解密用同一个密钥。最重要的问题是如何将密钥安全的发送给对方。
非对称加密使用一对非对称密钥:公钥和私钥。公钥随便发布,私钥只有自己知道。发送方用接收方的公钥进行加密,接收方用自己的私钥进行解密。
非对称加密更安全,但是很慢。所以我们用对称加密来传送消息,用非对称加密传输对称加密的密钥就可以了。

HTTP COOKIE SESSION

为什么要用cookie技术?因为HTTP是无状态的,不用cookie技术就会出现一直需要登陆的情况。
cookie和session都是在客户端和服务器之间保持状态的解决方案,cookie是在客户端保持状态的方案,session机制则采用的是在服务器端保持状态的方案。
Cookie实际上是一小段的文本信息。客户端请求服务器,如果服务器需要记录该用户状态,就使用response向客户端浏览器颁发一个Cookie,而客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时,浏览器把请求的网址连同该Cookie一同提交给服务器,服务器检查该Cookie,以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
同样地,会话状态也可以保存在服务器端。客户端请求服务器,如果服务器记录该用户状态,就获取Session来保存状态,这时,如果服务器已经为此客户端创建过session,服务器就按照sessionid把这个session检索出来使用;如果客户端请求不包含sessionid,则为此客户端创建一个session并且生成一个与此session相关联的sessionid,并将这个sessionid在本次响应中返回给客户端保存。保存这个sessionid的方式可以采用 cookie机制 ,这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器;若浏览器禁用Cookie的话,可以通过 URL重写机制 将sessionid传回服务器。

session 和 cookie区别
实现机制:Session的实现常常依赖于Cookie机制,通过Cookie机制回传SessionID;
大小限制:Cookie有大小限制并且浏览器对每个站点也有cookie的个数限制,Session没有大小限制,理论上只与服务器的内存大小有关;
安全性:Cookie存在安全隐患,通过拦截或本地文件找得到cookie后可以进行攻击,而Session由于保存在服务器端,相对更加安全;
服务器资源消耗:Session是保存在服务器端上会存在一段时间才会消失,如果session过多会增加服务器的压力。

SQL注入:

SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。
SQL注入攻击的总体思路:
寻找到SQL注入的注入点
判断服务器类型和后台数据库类型
针对不通的服务器和数据库特点进行SQL注入攻击

应对方法:参数绑定和用正则表达式过滤参数。
参数绑定就是把攻击者的查询语句变成参数,而不是SQL命令

XSS:

跨站脚本攻击。
预防:进行转码处理,将cookie设置成http-only.

TCP经典协议:

FTP 21
TELNET 远程登陆 23
SMTP 发邮件 25
POP3 接邮件 110
HTTP 超文本传输 80

UDP经典协议:

DNS 域名解析 53
SNMP 简单网络管理 161
TFTP 简单文件传输 69

HTTP状态码:

1XX:请求已被接受,正在处理
2XX: 请求被成功处理
3XX:重定向。要完成请求必须要做进一步处理
4XX:客户端错误,请求不合法。
5XX:服务器端错误,服务器不能处理合法请求。

细说Socket:

Socket处于应用层和传输层之间,提供了给应用层的接口。
Socket客户端与服务器通信流程:
服务端SOCKET创建一个新的通讯端点---->bind往套接字中附加本地的IP地址和端口号-------> listen 宣布愿意接受连接,使得socket处于listening状态,可以指定最大连接数。---->ACCEPT阻塞等待远程连接请求的到达
客户端Socket创建一个新的通讯端点---->connect建立连接
当客户端将建立连接请求发出后,服务端的accept阻塞也就结束了。
然后不断的传送数据,然后close客户端断开连接,服务器也close断开连接了。
tips:因为客户端跟服务器连接的话只有一个连接,所以这个通信端点就可以认为是一个连接了。因为它不需要阻塞。

python socket的具体函数:

import socket
Server = socket.socket(socket.AF_INET,socket.SOCK_STREAM) # 创建通信端点
Server.bind(('127.0.0.1',31232)) # 绑定端口
Server.listen(5) # 设置最大半连接数
conn,addr = Server.accept() # 阻塞 返回连接和客户端地址
msg = conn.recv(1024) # 连接接收最大为1024字节的bytes-like obj
print(msg.decode())
conn.close() # 断开连接
Server.close() # 关闭通信端点
import socket
client = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
client.connect(('127.0.0.1',31232))
msg = client.recv(1024)
print(msg.decode())
client.close()

send方法和recv方法操作的都是bytes-like object

UDP SERVER

import socket
server = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
server.bind(('localhost',12306))
while True:
    msg,addr = server.recvfrom(1024)
    print(msg.decode())
    msg = input().encode()
    server.sendto(msg,addr)

UDP CLIENT

import socket
client = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
while True:
    msg = input().encode()
    client.sendto(msg,('localhost',12306))
    msg,addr = client.recvfrom(1024)
    print(msg.decode())

代码体现了底层的原理。
由于TCP的机制,所以TCP服务器需要listen和accept。而UDP的服务器就不需要。
TCP的客户端需要connect主动发起TCP连接,UDP的客户端就不需要。
由于TCP需要建立连接,所以拿到客户端的连接和地址是用accept拿到的。拿到之后就建立了连接,所以recv只需要接收msg就可以了,不需要再接收addr了。由于建立了连接,所以只需要send一个bytes-like object就可以了,不用指定发给谁。

而UDP不需要建立连接,用recvfrom收到一条东西就得拆开看看这是谁发来的。因为它是无连接的。由于没有连接,所以sendto需要msg,还需要指定一个addr
所以UDP传输时才会用sendto和recvfrom 这完全是协议本身所导致的。
而且TCP是要把数据分开传输的,所以Python提供的send()并不能保证一次发送完所有的数据,所以又提供了sendall()用来一次发送完所有数据。不用担心,分包是在底层进行的。正常情况下,我们都应该使用sendall而非send。除非是crack想干点什么坏事。

猜你喜欢

转载自blog.csdn.net/weixin_41687289/article/details/83538493
今日推荐