OSI七层模型和TCP/IP四层模型
OSI七层模型:OSI(Open System Interconnection)开放系统互连参考模型是国际标准化组织(ISO)制定的一个用于计算机或通信系统间互联的标准体系。
TCP/IP四层模型:TCP/IP参考模型是计算机网络的祖父ARPANET和其后继的因特网使用的参考模型。
TCPIP四层,网络接口层-互联网络层-传输层-应用层
七层模型优点:
1、把复杂的网络划分成为更容易管理的层(将整个庞大而复杂的问题划分为若干个容易处理的小问题)
2、没有一个厂家能完整的提供整套解决方案和所有的设备,协议.
3、独立完成各自该做的任务,互不影响,分工明确,上层不关心下层具体细节,分层同样有益于网络排错
为什么现代网络通信过程中用TCP/IP四层模型,而不是用OSI七层模型呢?
OSI七层模型是理论模型,一般用于理论研究,他的分层有些冗余,实际应用,选择TCP/IP的四层模型。而且 OSI 自身也有缺陷,大多数人都认为 OSI 模型的层次数量与内容可能是最佳的选择,其实并非如此,其中会话层和表示层几乎是空的,而数据链路层和网络层包含内容太多,有很多的子层插入,每个子层都有不同的功能。
常见网络相关的协议
ARP
(Address Resolution Protocol):地址解析协议,将IP解析成MAC地址
DNS(53)
:域名解析协议 www.baidu.com
SNMP
(Simple Network Management Protocol)网络管理协议
DHCP
(Dynamic Host Configuration Protocol)动态主机配置协议,它是在TCP/IP网络上使客户机获得配置信息的协议
FTP(20)(21)
(File Transfer Protocol)文件传输协议,它是一个标准协议,是在计算机和网络之间交换文件的最简单的方法。
HTTP(80)
(Hypertext Transfer Protocol ):超文本传输协议
HTTPS(443)
(Secure Hypertext Transfer Protocol):安全超文本传输协议,它是由Netscape开发并内置于其浏览器中,用于对数据进行压缩和解压操作.
ICMP
(Internet Control Message Protocol):Internet控制信息协议,互联网控制报文协议
ping ip定义消息类型有:TTL超时、地址的请求与应答、信息的请求与应答、目的地不可到达
SMTP(25)
(Simple Mail Transfer Protocol):简单邮件传送协议
TELNET(23)
Protocol:虚拟终端协议
TFTP
(Trivial File Transfer Protocol):小文件传输协议
UDP
(User Datagram Protocol):用户数据报协议,它是定义用来在互连网络环境中提供包交换的计算机通信的协议
TCP
(Transmission Control Protocol): 传输控制协议,是一种面向连接的、可靠的、基于字节流的传输层通信协议 log转发:开启一个协议:tcp(三次握手和四次挥手)
TCP协议和UDP协议的区别
(1)TCP协议:TCP(Transmission Control Protocol,传输控制协议)是面向连接的协议,在收发数据前,必须和对方建立可靠的连接。
(2)UDP协议:UDP 是User Datagram Protocol的简称, 中文名是用户数据报协议,是一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务
总结:TCP与UDP的区别:
1.基于连接与无连接;
2.对系统资源的要求(TCP较多,UDP少);
3.UDP程序结构较简单;UDP信息包的标题很短,只有8个字节,相对于TCP的20个字节信息包的额外开销很小。所以传输速度可更快
4.TCP保证数据正确性,UDP可能丢包;TCP保证数据顺序,UDP不保证。
场景: 视频,语音通讯使用udp,或网络环境很好,比如局域网中通讯可以使用udp。 udp数据传输完整性,可以通过应用层的软件来校对就可以了。
tcp传文件,数据完整性要求高。
vim /etc/services
#此文件中,包含所有常见端口号及服务名称
#此文件可以查看常用端口对应的名字。iptables或netstat要把端口解析成协议名时,都需要使用到这个文件。另外后期xinetd服务管理一些小服务时,也会使用到此文件来查询对应的小服务端口号。
注:有的服务是UDP和TCP端口都会监听的
IP地址分类
IP地址分5类,常见的地址是A、B、C 三类
A类地址:0-127,0是保留的并且表示所有IP地址,而127也是保留的地址,并且是用于测试环回口用的。因此A类地址的可用的范围其实是从1-126之间。以子网掩码:255.0.0.0.这个127网段都用于环回口
B类地址:128-191,如172.168.1.1,以子网掩码来进行区别:255.255.0.0
C类地址:192-223,以子网掩码来进行区别: 255.255.255.0
D类地址:224-239,被用在多点广播(Multicast)中。多点广播地址用来一次寻址一组计算机,它标识共享同一协议的一组计算机。
E类地址:240-254,为将来使用保留。
ABC 3类中私有IP地址范围:
A:10.0.0.0–10.255.255.255 /8
B: 172.16.0.0–172.31.255.255 /16
C: 192.168.0.0–192.168.255.255 /24
linux网络相关的调试命令
mii-tool ens33
#查看网卡是否连接正常
ens33: negotiated 1000baseT-FD flow-control, link ok
ifconfig
#查看网络参数
常见的一些网络接口
eth0 … eth4 … 以太网接口(linux6)
waln0 无线接口
eno177776 以太网接口 (linux7)
ens33 以太网接口(linux7)
bond0 team0 网卡绑定接口
virbr0 虚拟交换机桥接接口
br0 虚拟网桥接口
lo 本地回环接口
vnet0 KVM虚拟机网卡接口
修改网卡IP地址
vim /etc/sysconfig/network-scripts/ifcfg-ens33
TYPE=Ethernet #设置类型是以太网设备,如图:
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none # 参数:static静态IP 或dhcp 或none无(不指定),如是none,配上IP地址和static效果一样
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=ens33 #网卡名字
UUID=c713acec-674b-411d-9e61-646482a292ca #网卡UUID,全球唯一
DEVICE=ens33 #设备名字,在内核中识别的名字
ONBOOT=yes #启用该设备,如果no,表示不启动此网络设备
IPADDR=192.168.1.63 #IP地址
PREFIX=24 #子网掩码,24相当于255.255.255.0(netmask)
GATEWAY=192.168.1.1 #默认网关
DNS1=114.114.114.114 #首选DNS地址
DNS2=8.8.8.8 #备用DNS地址
IPV6_PRIVACY=no
PEERDNS=no
ifconfig ens33 down
#关闭网卡 ifdown ens33
ifconfig ens38 up
#启动网卡 ifup ens33
ifconfig ens33:1 192.168.1.3 netmask 255.255.255.0
#临时给网卡配置多个ip地址
netstat -anutp
# 查看系统中网络连接状态信息,
-a, --all 显示本机所有连接和监听的端口
-n, --numeric don't resolve names 以数字形式显示当前建立的有效连接和端口
-u 显示udp协议连接
-t 显示tcp协议连接
-p, --programs 显示连接对应的PID与程序名
-l ,显示监听状态连接
Proto——————接协议的种类
Recv-Q——————接收到字节数
Send-Q——————从本服务器,发出去的字节数
Local Address———本地的IP地址,可以是IP,也可以是主机名
Foreign Address———远程主机的IP 地址
网络连接状态STATE:
- CLOSED : 初始(无连接)状态。
- LISTEN : 侦听状态,等待远程机器的连接请求。
- ESTABLISHED: 完成TCP三次握手后,主动连接端进入ESTABLISHED状态。此时,TCP连接已经建立,可以进行通信。
- TIME_WAIT : 在TCP四次挥手时,主动关闭端发送了ACK包之后,进入TIME_WAIT状态,等待最多MSL时间,让被动关闭端收到ACK包。
扩展:MSL
MSL,即Maximum Segment Lifetime,一个数据分片(报文)在网络中能够生存的最长时间,在RFC 793中定义MSL通常为2分钟,即超过两分钟即认为这个报文已经在网络中被丢弃了。对于一个TCP连接,在双方进入TIME_WAIT后,通常会等待2倍MSL时间后,再关闭掉连接,作用是为了防止由于FIN报文丢包,对端重发导致与后续的TCP连接请求产生顺序混乱
服务器上有大量TIME_WAI连接,如何优化TCP连接,快速释放tcp连接 ?
netstat -antup | grep TIME_WAI
tcp 0 0 123.57.82.225:80 111.196.245.241:4002 TIME_WAIT -
tcp 0 0 123.57.82.225:80 111.196.245.241:3970 TIME_WAIT -
tcp 0 0 123.57.82.225:80 111.196.245.241:4486 TIME_WAIT -
tcp 0 0 123.57.82.225:80 111.196.245.241:3932 TIME_WAIT -
tcp 0 0 123.57.82.225:80 111.196.245.241:3938 TIME_WAIT -
linux下默认MSL等待时间是60秒
cat /proc/sys/net/ipv4/tcp_fin_timeout
60
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeou
t #通过缩短时间time_wait时间来快速释放链接
vim /etc/hostname
#修改主机名永久生效
vim /etc/hosts
#优先级高于DNS解析
cat /etc/resolv.conf
#DNS配置的配置文件
在centos5版本,配置DNS用这个文件。在centos6以后,直接在网卡配置文件中指定:DNS1=192.168.1.1
默认情况下,域名解析顺序: 本地hosts文件-》DNS查询
本机域名解析顺序
vim /etc/nsswitch.conf
#查找以下内容
#hosts: db files nisplus nis dns
hosts: files dns myhostname #可以看到是先查看 files hosts文件,再查看DNS的
route -n
#查看路由信息
- -n :不要使用通讯协定或主机名称,直接使用 IP 或 port number;
route命令输出的路由表字段含义如下:
Destination 目标 :The destination network or destination host. 目标网络或目标主机。
Gateway 网关 :网关地址,如果是本地网段IP,就显示0.0.0.0
Genmask :子网掩码
0.0.0.0,则表示所有的IP地址,或者是没有IP地址。
route add [-net|-host] [网域或主机] netmask [mask] [gw|dev]
route del [-net|-host] [网域或主机] netmask [mask] [gw|dev]
增加 (add) 与删除 (del) 路由的相关参数:
- -net :表示后面接的路由为一个网域;
- -host :表示后面接的为连接到单部主机的路由;
- netmask :与网域有关,可以设定 netmask 决定网域的大小;
- gw :gateway 的简写,后续接的是 IP 的数值喔,与 dev 不同;
- dev :如果只是要指定由那一块网路卡连线出去,则使用这个设定,后面接 eth0 等
实战场景:多个网卡,多个网段,实现不同数据走不同网卡。如果网络管理和生产数据分开管理。 添加路由(把Linux做成路由器时或服务器有多个网卡,指定到不同网段走哪个网卡)
route add -net 192.168.172.0 netmask 255.255.255.0 dev ens34
#添加路由
route del -net 192.168.172.0 netmask 255.255.255.0
#删除路由
可以添加静态路由实现不同网段通信,a–1.0–b--2.0–c
a: route add -net 192.168.2.0/24 gw 192.168.1.1
b: 开启内核转发功能 vim /etc/sysctl.conf
net.ipv4.ip_forward = 1
c: route add -net 192.168.1.0 gw 192.168.2.1
traceroute
/'treisəru:t/ #路由追踪命令
实战场景: 新上线的服务器 , 北京用户需要经过几跳可以到达服务器。
tratceroute www.baidu.com
ping命令的一般格式为:
-c 数目 在发送指定数目的包后停止。
-i 秒数 设定间隔几秒送一个网络封包给一台机器,预设值是一秒送一次。
-I #可以指定从哪个接口出去
ping -I ens33 192.168.1.1
#指定从ens33接口出去
arping -I ens33 192.168.1.1
#查看网关是否有冲突(arp欺骗)(大写i)
ARPING 192.168.1.1 from 192.168.1.63 ens33
Unicast reply from 192.168.1.1 [80:9F:AB:08:EB:CA] 3.786ms
Unicast reply from 192.168.1.1 [80:9F:AB:08:EB:CA] 2.631ms
watch
#:实时监测命令的运行结果,可以看到所有变化数据包的大小
-d, --differences ['dɪfərəns] #高亮显示指令输出信息不同之处;
-n, --interval seconds [ˈɪntəvl] #指定指令执行的间隔时间(秒);
例1:每隔1秒高亮差异显示ens33相关信息
watch -d -n 1 "ifconfig ens33"
#动态查询ens33信息
Ctrl+c 就可以退出~
nc命令
什么是nc
nc是netcat的简写,有着网络界的瑞士军刀美誉。因为它短小精悍、功能实用,被设计为一个简单、可靠的网络工具
nc的作用
(1)实现任意TCP/UDP端口的侦听,nc可以作为server以TCP或UDP方式侦听指定端口
(2)端口的扫描,nc可以作为client发起TCP或UDP连接
(3)机器之间传输文件
(4)机器之间网络测速
nc的控制参数不少,常用的几个参数如下所列:
1) -l
nc -l 9999
用于指定nc将处于侦听模式。指定该参数,则意味着nc被当作server,侦听并接受连接,而非向其它地址发起连接。
2) -p <port>
暂未用到(老版本的nc可能需要在端口号前加-p参数,下面测试环境是centos6.6,nc版本是nc-1.84,未用到-p参数)
3) -s
指定发送数据的源IP地址,适用于多网卡机
4) -u
指定nc使用UDP协议,默认为TCP
5) -v
输出交互或出错信息,新手调试时尤为有用
6)-w
超时秒数,后面跟数字
7)-z
表示zero,表示扫描时不发送任何数据
nc -vz -w 2 192.168.1.1 9999 #测试
————————————————
版权声明:本文为CSDN博主「小毛毛2013」的原创文章,遵循CC 4.0 by-sa版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/u012486730/article/details/82019996
nmap 命令查看扫描查看端口。
yum install nmap
nmap -sTU localhost或ip
#扫描本机的tcp和udp端口开放状态。默认不加参数显示tcp端口
namp -sP 192.168.1.0/24
#通过icmp方式检测局域网中的主机
namp 192.168.1.0/24
#扫描网络上主机开放的端口。
TCP知识
ACK : TCP协议规定,只有ACK=1时有效,也规定连接建立后所有发送的报文的ACK必须为1
SYN(SYNchronization) : 在连接建立时用来同步序号。当SYN=1而ACK=0时,表明这是一个连接请求报文。对方若同意建立连接,则应在响应报文中使SYN=1和ACK=1. 因此, SYN置1就表示这是一个连接请求或连接接受报文。
synchronization [ˌsɪŋkrənaɪ’zeɪʃn] 同步
FIN (finis)即完,终结的意思, 用来释放一个连接。当 FIN = 1 时,表明此报文段的发送方的数据已经发送完毕,并要求释放连接。
finis ['faɪnɪs] 终结
TCP三次握手
1.第一次握手:建立连接时,客户端发送syn包(syn=x)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。
2.第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器从listen(监听状态)进入**SYN_RECV **(同步等待)状态;
3.第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。
TCP连接状态详解:
服务器端:LISTEN:侦听来自远方的TCP端口的连接请求
客户端:SYN-SENT:在发送连接请求后等待匹配的连接请求
服务器端:SYN-RECEIVED:在收到和发送一个连接请求后等待对方对连接请求的确认
客户端/服务器端:ESTABLISHED:代表一个打开的连接
TCP四次挥手*
1.客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
2.服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
3.客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
4.服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
5.客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
6.服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。
常见面试题
【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?
答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。
【问题3】为什么不能用两次握手进行连接?
答:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。
【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
在局域网中使用 awl伪装IP地址进行多线程SYN洪水攻击
SYN洪水攻击概述:SYN洪水攻击主要源于: tcp协议的三次握手机制
在服务端返回一个确认的SYN-ACK包的时候有个潜在的弊端,如果发起的客户是一个不存在的客户端,那么服务端就不会接到客户端回应的ACK包。
这时服务端需要耗费一定的数量的系统内存来等待这个未决的连接,直到等待超关闭,才能施放内存。
如果恶意者通过通过ip欺骗,发送大量SYN包给受害者系统,导致服务端存在大量未决的连接并占用大量内存和tcp连接,从而导致正常客户端无法访问服务端,这就是SYN洪水攻击的过程。
下载地址:https://gitlab.com/davical-project/awl/tags