|
|
|
@ -9,7 +9,7 @@
|
|
|
|
|
TCP(Transmission Control Protocol传输控制协议)是一种面向连接的、
|
|
|
|
|
可靠的、基于字节流的传输层通信协议。
|
|
|
|
|
本实验通过运用Wireshark对网络活动进行抓包分析,
|
|
|
|
|
让学生观察TCP协议报文,分析通信时序,帮助同学理解TCP的工作过程,
|
|
|
|
|
观察TCP协议报文,分析通信时序,理解TCP的工作过程,
|
|
|
|
|
掌握TCP工作原理与实现;
|
|
|
|
|
学会运用Wireshark分析TCP连接管理、流量控制和拥塞控制的过程,发现TCP的性能问题。
|
|
|
|
|
|
|
|
|
@ -24,7 +24,7 @@ TCP(Transmission Control Protocol传输控制协议)是一种面向连接的、
|
|
|
|
|
(例如,尝试连接未存活的主机或未监听端口或客户端发送了第一个SYN连接请求而服务端无响应);
|
|
|
|
|
观察SYN洪泛影响;观察分析TCP通信过程中的各类异常报文(例如数据超时、乱序),
|
|
|
|
|
了解其触发机制与含义。
|
|
|
|
|
\item 流量控制(进阶):运行一组TCP连接客户端/服务器程序(Python代码见附录),
|
|
|
|
|
\item 流量控制(进阶):运行一组TCP连接客户端/服务器程序(Python代码见节后附件),
|
|
|
|
|
制造收发不平衡场景,观察收发报文中通告窗口的变化,分析与窗口机制相关的类型报文,
|
|
|
|
|
了解滑动窗口工作原理。
|
|
|
|
|
\item 拥塞控制(进阶):改变带宽、时延、丢包率等网络参数,观察大文件传输过程,
|
|
|
|
@ -41,10 +41,8 @@ TCP(Transmission Control Protocol传输控制协议)是一种面向连接的、
|
|
|
|
|
TCP协议基于“尽力而为”的网络层为应用层提供可靠的进程间通信服务,
|
|
|
|
|
具体地说是可靠的全双工的端对端字节流传输服务。
|
|
|
|
|
在TCP的协议传输单元中(TCP报文段,TCP Segment),
|
|
|
|
|
发送方和接收方使用字节序号(Sequence Number)明确收发的数据,并精确到字节单位;
|
|
|
|
|
收发双方以字节为单位使用序号(Sequence Number)明确收发的数据,
|
|
|
|
|
使用ACK反馈(Acknowledgment)机制,实现端对端的可靠传输控制。
|
|
|
|
|
接下来,简要介绍TCP报文段的结构,
|
|
|
|
|
TCP的连接管理、差错控制、流量控制和拥塞控制的原理。
|
|
|
|
|
|
|
|
|
|
\paragraph{TCP报文段(Segment)}~{}
|
|
|
|
|
\\
|
|
|
|
@ -55,7 +53,7 @@ TCP 报文段结构如图\ref{fig:c:wireshark_TCP-structure}所示,
|
|
|
|
|
\begin{figure}[!ht]
|
|
|
|
|
\centering
|
|
|
|
|
\includegraphics[width=10cm]{TCP-structure}
|
|
|
|
|
\caption{TCP报文段结构标意图}
|
|
|
|
|
\caption{TCP报文段结构示意图}
|
|
|
|
|
\label{fig:c:wireshark_TCP-structure}
|
|
|
|
|
\end{figure}
|
|
|
|
|
|
|
|
|
@ -63,25 +61,25 @@ TCP 报文段结构如图\ref{fig:c:wireshark_TCP-structure}所示,
|
|
|
|
|
|
|
|
|
|
\begin{enumerate}
|
|
|
|
|
\item \textbf{源端口号(Source Port):}16位的源端口,
|
|
|
|
|
与源IP地址一起标识发送该TCP 报文段的通信进程。端口号范围0\~65535。
|
|
|
|
|
与源IP地址一起标识发送该TCP报文段的通信进程。端口号范围0-65535。
|
|
|
|
|
\item \textbf{目的端口号(Destionation Port):}16位目的端口,
|
|
|
|
|
与目的IP地址一起标识接收该TCP 报文段的通信进程。端口号范围0\~65535。
|
|
|
|
|
\item \textbf{序号(Sequence Number):}该TCP 报文段中第一个数据字节的序号,占4个字节。在TCP连接建立时,通常生成一个随机数作为字节序列号的初始值(ISN)。
|
|
|
|
|
与目的IP地址一起标识接收该TCP报文段的通信进程。
|
|
|
|
|
\item \textbf{序号(Sequence Number):}该TCP报文段中第一个数据字节的序号,占4个字节。在TCP连接建立时,通常生成一个随机数作为字节序号的初始值(ISN)。
|
|
|
|
|
\item \textbf{确认号(Acknowledgement Number):}
|
|
|
|
|
表示期望收到对方下一个报文段的字节序号,占4个字节。
|
|
|
|
|
\item \textbf{标志位(TCP Flags):}
|
|
|
|
|
\begin{enumerate}
|
|
|
|
|
\item 确认ACK (Acknowledgement):置1表示确认号字段有效。
|
|
|
|
|
\item 推送PSH (Push):置1表示该报文段优先级高,
|
|
|
|
|
接收方 TCP 应该尽快推送给接收应用程序。
|
|
|
|
|
\item 复位RST(Reset):置1表示需要释放 TCP 连接并重新建立连接。
|
|
|
|
|
一般称携带 RST 标志的 TCP 报文段为「复位报文段」。
|
|
|
|
|
\item 确认ACK(Acknowledgement):置1表示确认号字段有效。
|
|
|
|
|
\item 推送PSH(Push):置1表示该报文段优先级高,
|
|
|
|
|
接收方TCP应尽快推送给接收应用程序。
|
|
|
|
|
\item 复位RST(Reset):置1表示需要释放TCP连接并重新建立连接。
|
|
|
|
|
一般称带RST标志的TCP报文段为“复位报文段”。
|
|
|
|
|
\item 同步SYN(Synchronization):置1表示这是TCP请求连接报文段。
|
|
|
|
|
一般称携带 SYN 标志的 TCP 报文段为“同步报文段”。
|
|
|
|
|
一般称带SYN标志的TCP报文段为“同步报文段”。
|
|
|
|
|
\item 终止FIN(Finish):置l表示发送方的数据已经发送完毕,
|
|
|
|
|
并要求释放 TCP 连接。
|
|
|
|
|
并要求释放TCP连接。
|
|
|
|
|
\end{enumerate}
|
|
|
|
|
\item \textbf{窗口大小(Window):}表示接收缓存大小,即暂时缓存接收的数据。
|
|
|
|
|
\item \textbf{窗口大小(Window):}表示接收缓存大小。
|
|
|
|
|
最早TCP协议首部只设置了16位的窗口大小,允许的最大缓存大小不超过64KB;
|
|
|
|
|
而RFC1323打破此限定,设置了TCP窗口缩放因子(Window size scaling factor),
|
|
|
|
|
使窗口大小等于二者的乘积。
|
|
|
|
@ -103,7 +101,7 @@ TCP 报文段结构如图\ref{fig:c:wireshark_TCP-structure}所示,
|
|
|
|
|
|
|
|
|
|
\textbf{建立过程:}TCP是面向连接的,数据传输之前必须在双方之间建立一条连接,
|
|
|
|
|
并通过三次握手过程完成。
|
|
|
|
|
其主要目的是,同步连接双方的序列号和确认号,并交换 TCP窗口大小等控制信息。
|
|
|
|
|
其主要目的是,同步连接双方的序号和确认号,并交换TCP窗口大小等控制信息。
|
|
|
|
|
一般地,客户端主动向服务器端发起连接请求,具体过程如下:
|
|
|
|
|
|
|
|
|
|
\begin{enumerate}
|
|
|
|
@ -128,7 +126,7 @@ TCP 报文段结构如图\ref{fig:c:wireshark_TCP-structure}所示,
|
|
|
|
|
服务器端完成数据发送之后,也发出FIN=1的报文请求释放连接,
|
|
|
|
|
并进入 LAST-ACK状态,直至客户端返回确认(第四次挥手)才关闭TCP连接。
|
|
|
|
|
客户端收到服务器的FIN报文后,则进入TIME\_WAIT状态,
|
|
|
|
|
并等待 2MSL(最大存活时间- Maximum Segment Lifetime)时间之后,完全关闭TCP连接。
|
|
|
|
|
并等待2MSL(最大存活时间- Maximum Segment Lifetime)时间之后,完全关闭TCP连接。
|
|
|
|
|
(注:释放连接也可由服务器端先发起)
|
|
|
|
|
|
|
|
|
|
\paragraph{TCP流量控制}~{}
|
|
|
|
@ -138,7 +136,7 @@ TCP 报文段结构如图\ref{fig:c:wireshark_TCP-structure}所示,
|
|
|
|
|
TCP利用滑动窗口(Sliding Window)机制实施流量控制,
|
|
|
|
|
其基本原理是用TCP报文段中的窗口大小字段来控制数据发送速率,
|
|
|
|
|
即发送方的发送窗口应小于接收方回应报文中的通告窗口值。
|
|
|
|
|
为了提高信道利用率,TCP采用了连续ARQ (Automatic Repeat reQuest),
|
|
|
|
|
为了提高信道利用率,TCP采用了连续ARQ(Automatic Repeat reQuest),
|
|
|
|
|
TCP两端都可以连续发出若干个分组然后等待确认,
|
|
|
|
|
也都设有发送/接收窗口和发送/接收缓存。
|
|
|
|
|
其中发送窗口可以用3个指针表示,
|
|
|
|
@ -182,7 +180,7 @@ cwnd初始值为1个MSS(Maximum Segment Size);
|
|
|
|
|
则启用快重传算法,并将cwnd重置为1,ssthresh减半。
|
|
|
|
|
|
|
|
|
|
TCP拥塞控制算法一直处在不断的改进之中,围绕对网络环境因素感知和拥塞避免的控制,
|
|
|
|
|
涌现了策略算法。TCP Reno继承Tahoe的三个算法并增加了快速恢复(Fast Recovery)算法。
|
|
|
|
|
涌现出新的策略算法。TCP Reno继承Tahoe的三个算法并增加了快速恢复(Fast Recovery)算法。
|
|
|
|
|
收到三个重复的ACK后,Reno会把当前的ssthresh的值设置为当前cwnd的一半,
|
|
|
|
|
并将cwnd更新为ssthresh+3MSS;然后每收到一个重复ACK则cwnd+1,
|
|
|
|
|
直至收到新确认号的ACK则将cwnd更新为ssthresh。
|
|
|
|
@ -199,11 +197,13 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
|
|
|
|
|
\subsubsection{实验方法和手段}
|
|
|
|
|
|
|
|
|
|
使用VMWare软件配置两台本地虚拟机,本地相互连接(如图\ref{fig:c:wireshark_TCP-topo})。
|
|
|
|
|
在VMWare中的虚拟机设置->网络适配器->高级中虚拟机的网卡传入/传出带宽、
|
|
|
|
|
传输速率、时延等,用来仿真不同的网络条件(如图\ref{fig:c:wireshark_VM-advance-setup})。
|
|
|
|
|
两台实验机本地相互连接(如图\ref{fig:c:wireshark_TCP-topo}),
|
|
|
|
|
在实验机中仿真不同的网络条件,以便观察TCP的各种控制现象。
|
|
|
|
|
方案一使用虚拟机:VMware Player中通过“虚拟机设置->硬件->网络适配器->高级”(如图\ref{fig:c:wireshark_VM-advance-setup})
|
|
|
|
|
设置虚拟机的网卡传入/传出带宽、数据包丢失率、延迟等;
|
|
|
|
|
方案二使用物理机:使用tc进行流量控制场景仿真,使用wondershaper对网卡进行限速。
|
|
|
|
|
本实验需要使用的命令和工具,如表\ref{tab:c:wireshark_tools-command}所列。
|
|
|
|
|
常用的Linux操作系统命令还包括:echo、cat、sysctl、ping、ftp。
|
|
|
|
|
常用的Linux命令还包括:echo、cat、sysctl、ping、ftp等。
|
|
|
|
|
|
|
|
|
|
\begin{figure}[!ht]
|
|
|
|
|
\centering
|
|
|
|
@ -225,7 +225,7 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
\centering
|
|
|
|
|
\caption{主要工具及命令列表}
|
|
|
|
|
\label{tab:c:wireshark_tools-command}
|
|
|
|
|
\begin{tabular}{|m{1.5cm}<{\centering}|m{3cm}<{\centering}|m{8.5cm}|}
|
|
|
|
|
\begin{tabular}{|m{2.5cm}<{\centering}|m{3cm}<{\centering}|m{8.5cm}|}
|
|
|
|
|
\hline
|
|
|
|
|
\heiti 命令 & \heiti 作用 & \multicolumn{1}{c|}{\heiti 参考}\\ \hline
|
|
|
|
|
\texttt{ifconfig} & 配置网络 & \url{https://man.linuxde.net/ifconfig}\\ \hline
|
|
|
|
@ -237,6 +237,7 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
\texttt{netwox} & 网络工具 & \url{https://sourceforge.net/projects/ntwox/}\\ \hline
|
|
|
|
|
\texttt{ss} & Socket状态 & \texttt{ss –atn}\\ \hline
|
|
|
|
|
\texttt{netstat} & 显示网络状态 & \texttt{netstat –atn}\\ \hline
|
|
|
|
|
\texttt{wondershaper} & 网卡限速工具 & \texttt{wondershaper [网口] [下载速率] [上行速率] wondershaper clear [网口]}\\ \hline
|
|
|
|
|
\texttt{iperf3} & 网络性能分析 & \url{https://iperf.fr/}\\ \hline
|
|
|
|
|
\end{tabular}
|
|
|
|
|
\end{table}
|
|
|
|
@ -245,17 +246,14 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
\label{subsec:c:wireshark:s:tcp_requirement}
|
|
|
|
|
|
|
|
|
|
\begin{enumerate}
|
|
|
|
|
\item 硬件:每个学生一台物理实验机(8G以上内存,80G以上硬盘空间)。
|
|
|
|
|
\item 软件:物理机装Windows7/10、VMWare或VisualBox;
|
|
|
|
|
两台 Ubuntu18虚拟机(每台2G内存、20G HD)。
|
|
|
|
|
每台Ubuntu虚机上预装wireshark、curl、vsftp、netwox、telnet、namp和iperf3。
|
|
|
|
|
\item 环境准备:分别以Ubuntu 1\#机、Ubuntu2\#机作为TCP的客户端与服务端,
|
|
|
|
|
以下简称1\#机,2\#机;设置虚机网络连接为NAT模式,IPv4设置为DHCP。
|
|
|
|
|
启动两台实验虚机后,可使用ping进行连接性测试,
|
|
|
|
|
\item 硬件:处于同一局域网的两台PC机(可使用虚拟机也可使用物理机)。
|
|
|
|
|
\item 软件:Ubuntu系统(18.04版),
|
|
|
|
|
预装wireshark、curl、vsftp、netwox、telnet、nmap和iperf3。
|
|
|
|
|
\item 环境准备:分别以PC1、PC2作为TCP的客户端与服务端;
|
|
|
|
|
启动两台实验机后,可使用ping进行连接性测试,
|
|
|
|
|
也可使用nmap扫一下对方打开的端口,
|
|
|
|
|
确保实验环境正常
|
|
|
|
|
(指导书中服务器的IP为192.168.100.144,指导书中命令若有用及此IP,
|
|
|
|
|
应替换为实际观察到的IP) 。
|
|
|
|
|
(指导书中PC2的IP为192.168.100.144,实验中应替换为实际的IP) 。
|
|
|
|
|
\end{enumerate}
|
|
|
|
|
参考资料:
|
|
|
|
|
|
|
|
|
@ -274,20 +272,20 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
|
|
|
|
|
\begin{enumerate}
|
|
|
|
|
\item 利用python自带的SimpleHTTPServer模块,
|
|
|
|
|
在2\#机上启动一个简易的web服务器。
|
|
|
|
|
在PC2上启动一个简易的web服务器。
|
|
|
|
|
终端上运行\texttt{echo "TCP lab test" > index.html}创建index.html文件为测试站首页,
|
|
|
|
|
运行\texttt{sudo python -m SimpleHTTPServer 80}启动一个简易web服务器;
|
|
|
|
|
打开新终端,键入\texttt{ss -tln}查看当前主机打开的TCP连接,确认80端口处理监听状态。
|
|
|
|
|
\item 在1\#机上打开一个终端,键入\texttt{sudo wireshark}启动抓包软件;
|
|
|
|
|
再打开一个新终端,键入 curl <2\#机IP> ;
|
|
|
|
|
\item 在PC1上打开一个终端,键入\texttt{sudo wireshark}启动抓包软件;
|
|
|
|
|
再打开一个新终端,键入 curl <PC2的IP> ;
|
|
|
|
|
停止抓包,在wireshark过滤出TCP类型报文。
|
|
|
|
|
观察首个TCP报文头,并分析各段值代表的意义。
|
|
|
|
|
如果想要关闭相对序列号/确认号,
|
|
|
|
|
如果想要关闭相对序号/确认号,
|
|
|
|
|
可以选择Wireshark菜单栏中的
|
|
|
|
|
Edit$\rightarrow$Preference$\rightarrow$protocols$\rightarrow$TCP,
|
|
|
|
|
去掉Relative sequence number勾选项。
|
|
|
|
|
使用Wireshark内置的绘制流功能,选择菜单栏中的Statistics$\rightarrow$Flow Graph,
|
|
|
|
|
Flow Type选择TCP flows可以直观地显示TCP序列号和确认号是如何工作的。
|
|
|
|
|
Flow Type选择TCP flows可以直观地显示TCP序号和确认号是如何工作的。
|
|
|
|
|
\item 观察TCP三次握手与四次挥手报文,注意报文收发过程中,双方TCP状态的变化。
|
|
|
|
|
以本次抓得报文为据,分别画出本次TCP连接三次握手与四次挥手的时序图,
|
|
|
|
|
结合TCP状态机,在双方各阶段标出对应的TCP状态。选择其中一个TCP报文,
|
|
|
|
@ -310,7 +308,7 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
\item 再次curl访问,观察抓包内容。
|
|
|
|
|
\item 关闭服务器端的SimpleHTTPServer(ctrl+C中断,或关闭所在终端),
|
|
|
|
|
客户端curl访问服务器80端口,观察应答报文。
|
|
|
|
|
\item 运行\texttt{nmap -sS <2\#机IP>}扫描服务器,并抓包。
|
|
|
|
|
\item 运行\texttt{nmap -sS <PC2的IP>}扫描服务器,并抓包。
|
|
|
|
|
\item 在报告中总结以上观察结果,解释SYN扫描原理。
|
|
|
|
|
\end{enumerate}
|
|
|
|
|
\item 客户端发送了第一个SYN连接请求,服务器无响应的情景。
|
|
|
|
@ -326,8 +324,8 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
\item 观察TCP的状态变化,分析wireshark抓到的TCP异常报文。
|
|
|
|
|
\item 服务端的SYN-RECV 状态何时释放?
|
|
|
|
|
\item SYN ACK重传了几次,时间间隔有何变化?
|
|
|
|
|
\item 参考(1)在服务端修改SYN ACK重传次数(tcp\_synack\_retries),
|
|
|
|
|
再次观察,此任务结束后清空防火墙规则(iptables -F)。
|
|
|
|
|
\item 参考1中的操作,在服务端修改SYN ACK重传次数(tcp\_synack\_retries),
|
|
|
|
|
再次观察,此任务结束后清空防火墙规则(iptables -F)。
|
|
|
|
|
\end{enumerate}
|
|
|
|
|
\item SYN洪泛。
|
|
|
|
|
在服务器端\texttt{sudo echo "0">/proc/sys/net/ipv4/tcp\_syncookies}禁用syncookies,
|
|
|
|
@ -344,18 +342,18 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
\item 产生一个100M文件:
|
|
|
|
|
|
|
|
|
|
\texttt{dd if=/dev/zero of=100M.file bs=1M count=100}
|
|
|
|
|
\item 模拟网络抖动:
|
|
|
|
|
\item 模拟网络延迟、包重复、包乱序、包损坏:
|
|
|
|
|
|
|
|
|
|
\texttt{tc qdisc add dev ens33 root netem delay 70ms 10ms 30\% duplicate 1\% reorder 5\% 10\% corrupt 0.1\%}
|
|
|
|
|
|
|
|
|
|
(将此行命令的add改为change即修改、del即删除此行规则)。
|
|
|
|
|
(调整上述命令中的数值,以达到期望效果;将此行命令的add改为change/del即修改/删除此规则。)
|
|
|
|
|
\item 下载服务器上的大文件:\texttt{wget 192.168.100.144/100M.file}
|
|
|
|
|
\end{enumerate}
|
|
|
|
|
|
|
|
|
|
抓包记录以上过程,分析黑色标签错误报文,结合TCP实现机制,
|
|
|
|
|
分析这些报文产生的原因。此类报文也可以从现实网络行为抓取获得,
|
|
|
|
|
请结合实际抓得报文分析,报文附件随报告提交。
|
|
|
|
|
包含但不限于以下几种类型报文:
|
|
|
|
|
包括但不限于以下几种类型报文:
|
|
|
|
|
[Duplicate ACK]、[TCP Retransmission]、[Fast Retransmission]、
|
|
|
|
|
[TCP Spurious Retransmission]、[TCP Out-Of-Order]、
|
|
|
|
|
[TCP Previous segment not captured]。
|
|
|
|
@ -378,8 +376,9 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
|
|
|
|
|
\subsubsection{拥塞控制}
|
|
|
|
|
\begin{enumerate}
|
|
|
|
|
\item 在VMWare中的虚拟机设置$\rightarrow$网络适配器$\rightarrow$高级中设置,
|
|
|
|
|
设置两台虚拟机的网卡传入/传出带宽为10Mbps以下,
|
|
|
|
|
\item 任一端限制网卡传入/传出带宽为10Mbps以下:使用虚拟机作为实验机,可
|
|
|
|
|
在VMWare Player中的虚拟机设置$\rightarrow$网络适配器$\rightarrow$高级中设置;
|
|
|
|
|
物理机可使用wondershaper命令进行限速。
|
|
|
|
|
再启动应用(可以是http wget,也可以ftp下载/上传)传输大文件观察。
|
|
|
|
|
\item Wireshark抓取全部传输过程数据,找出该网络活动的拥塞点,
|
|
|
|
|
并结合Analyze$\rightarrow$Expert Information、Statistic$\rightarrow$IO Graphs、
|
|
|
|
@ -418,19 +417,19 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
|
|
|
|
|
\begin{enumerate}
|
|
|
|
|
\item TCP在不可靠的IP层上建立了可靠的端对端连接,
|
|
|
|
|
如何在不可靠的UDP上建立可靠的端对端传输系统呢?
|
|
|
|
|
如果要在不可靠的UDP上建立可靠的端对端传输系统,需要考虑哪些方面?
|
|
|
|
|
\item TCP连接建立过程中,存在哪些等待队列?
|
|
|
|
|
这些队列是否可能出现溢出状况,高并发TCP连接应用如何调优?
|
|
|
|
|
\item 本次实验观察了Linux环境下的TCP实现,在Windows、MacOS环境下,
|
|
|
|
|
这些队列是否可能出现溢出状况?该如何避免?
|
|
|
|
|
\item 本次实验观察了Linux环境下的TCP实现,在Windows、macOS环境下,
|
|
|
|
|
操作系统又是如何实现TCP的呢?
|
|
|
|
|
类似Linux TCP参数,在不同系统环境下如何查看或设置,
|
|
|
|
|
请尝试通过抓包其通信过程发现其实现异同。
|
|
|
|
|
\item TCP是封装单元为MSS,可是我们在抓包过程中常发现远大于此值的TCP包,
|
|
|
|
|
为什么TCP可以提交如此大的报文呢?
|
|
|
|
|
此类型的包远超出链路层的MTU,它是如何被处理的呢?请从两端同时抓包观察比对。
|
|
|
|
|
\item 在TCP状态机(图\ref{fig:c:wireshark_TCP-status-machine})中,
|
|
|
|
|
有些状态停留时间较长,易观察到,有些状态很短暂不易观察到。
|
|
|
|
|
试列出不易观察到的状态,并考虑观察到它们的可能方法。
|
|
|
|
|
\item TCP是封装单元为MSS,可是我们在抓包过程中常发现远大于此值的TCP包,
|
|
|
|
|
为什么TCP可以提交如此大的报文呢?
|
|
|
|
|
此类型的包远超出链路层的MTU,它是如何被处理的呢?请从两端同时抓包观察比对。
|
|
|
|
|
|
|
|
|
|
\begin{figure}[!ht]
|
|
|
|
|
\centering
|
|
|
|
@ -453,9 +452,10 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
\item 环境还原:前面操作的iptables、tc遗留规则可能会影响后面的操作效果,
|
|
|
|
|
\texttt{iptables --list}查看核对一下当前的规则,
|
|
|
|
|
\texttt{iptables -F}清空当前规则;
|
|
|
|
|
同样,使用\texttt{tc qdisc del dev eth0 root RULE}清除网卡eth0队列规则。
|
|
|
|
|
同样,使用\texttt{tc qdisc del dev eth0 root RULE}清除网卡eth0队列规则;
|
|
|
|
|
wondershaper限速使用clear参数清除。
|
|
|
|
|
使用虚拟机的快照功能是更原始、更彻底的还原方式。
|
|
|
|
|
\item 批量网络扫描是威害网络行为,仅在实验室环境下进行试验学习,
|
|
|
|
|
\item 批量网络扫描是危害网络行为,仅在实验室环境下进行试验学习,
|
|
|
|
|
不得用于运营网络。
|
|
|
|
|
\end{enumerate}
|
|
|
|
|
|
|
|
|
@ -465,7 +465,7 @@ BBR\footnote{\href{https://queue.acm.org/detail.cfm?id=3022184}{BBR: Congestion-
|
|
|
|
|
完成本次实验,并提交一份实验报告和一组Wireshark数据存储文件。
|
|
|
|
|
报告内容应当包括以下部分,相关的分析解释都对应有截图证明,并与数据存储文件吻合。
|
|
|
|
|
\begin{enumerate}
|
|
|
|
|
\item (20分) 正确绘制出了三次握手报文与四次挥手报文(须结合抓得报文序号),
|
|
|
|
|
\item (20分) 正确绘制出了三次握手报文与四次挥手报文(须结合捕获的报文),
|
|
|
|
|
并正确标识出了各阶段TCP状态;
|
|
|
|
|
\item (20分) 观察传输异常现象,并进行分析;
|
|
|
|
|
\item (20分) 完成流量控制操作要求,结合上下分析报文窗口变化,
|
|
|
|
|