计算机网络知识——TCP
计算机网络-内核
- 网络模型
-
- 七层OSI模型
- 四层TCP/IP模型
-
- 简化的结构
- 三次握手，四次挥手
- 本地客户端与百度www.baidu.com如何交互？
-
- 创建socket,客户端使用网络协议发送请求，在接受服务端数据
- 用 netstat -natp 监控网络连接情况
- 网卡信息
- route -n
- 如何验证？
-
- 结论：
网络模型
七层OSI模型
略 https://www.cnblogs.com/fanBlog/p/12395825.html
四层TCP/IP模型
摘自
https://blog.csdn.net/be_happy_mr_li/article/details/52243006?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param
简化的结构
https://www.processon.com/diagraming/5f8c0855f346fb06e1daf0ed
三次握手，四次挥手
理论略
本地客户端与百度www.baidu.com如何交互？
创建socket,客户端使用网络协议发送请求，在接受服务端数据
[root@node01 ~]# cd /proc/$$/fd
//本地的/proc/$$/fd 中的8号文件描述符，通过socket 和百度地址建立了连接
[root@node01 fd]# exec 8<> /dev/tcp/www.baidu.com/80
//然后在客户端层面按照 网络协议HTTP，发送请求头，socket重定向到1标准输出
[root@node01 fd]# echo -e "GET / HTTP/1.0\n" 1>& 8
//cat 通过socket将百度响应返回的数据，作为本地客户端当前shell的cat 的输入
[root@node01 fd]# cat 0<& 8
查看文件描述符
显示百度返回的信息
传输控制层
TCP协议
面向连接的，可靠的传输协议
面向连接：三次握手，传输数据，四次挥手
socket：【ip+port 】 【ip+port】
port ：65535个
开启资源，用于连接
用 netstat -natp 监控网络连接情况
curl www.baidu.com
tcpdum 可以查看到，先三次握手，再传输数据，断开连接，四次挥手的具体过程
查看 man tcpdump 得知
Flags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo), or a single ‘.’ (no flags).
Src and dst are the source and destination IP addresses and ports. Flags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo), or a single ‘.’ (no flags). Data-
seqno describes the portion of sequence space covered by the data in this packet (see example below).
Ack is sequence number of the next data expected the other direction on this connection. Window is
the number of bytes of receive buffer space available the other direction on this connection. Urg
indicates there is ‘urgent’ data in the packet. Options are tcp options enclosed in angle brackets
(e.g., <mss 1024>).
Src, dst and flags are always present. The other fields depend on the contents of the packet’s tcp
protocol header and are output only if appropriate.
Here is the opening portion of an rlogin from host rtsg to host csam.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
seqno describes the portion of sequence space covered by the data in this packet (see example below).
Ack is sequence number of the next data expected the other direction on this connection. Window is
the number of bytes of receive buffer space available the other direction on this connection. Urg
indicates there is ‘urgent’ data in the packet. Options are tcp options enclosed in angle brackets
(e.g., <mss 1024>).
Src, dst and flags are always present. The other fields depend on the contents of the packet’s tcp
protocol header and are output only if appropriate.
Here is the opening portion of an rlogin from host rtsg to host csam.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
The first line says that tcp port 1023 on rtsg sent a packet to port login on csam. The S indicates
that the SYN flag was set. The packet sequence number was 768512 and it contained no data. (The
notation is ‘first:last(nbytes)’ which means ‘sequence numbers first up to but not including last
which is nbytes bytes of user data’.) There was no piggy-backed ack, the available receive window
was 4096 bytes and there was a max-segment-size option requesting an mss of 1024 bytes.
Csam replies with a similar packet except it includes a piggy-backed ack for rtsg’s SYN. Rtsg then
acks csam’s SYN. The ‘.’ means no flags were set. The packet contained no data so there is no data
sequence number. Note that the ack sequence number is a small integer (1). The first time tcpdump
sees a tcp ‘conversation’, it prints the sequence number from the packet. On subsequent packets of
the conversation, the difference between the current packet’s sequence number and this initial
sequence number is printed. This means that sequence numbers after the first can be interpreted as
relative byte positions in the conversation’s data stream (with the first data byte each direction
being ‘1’). ‘-S’ will override this feature, causing the original sequence numbers to be output.
On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20 in the rtsg → csam side of the
conversation). The PUSH flag is set in the packet. On the 7th line, csam says it’s received data
sent by rtsg up to but not including byte 21. Most of this data is apparently sitting in the socket
buffer since csam’s receive window has gotten 19 bytes smaller. Csam also sends one byte of data to
rtsg in this packet. On the 8th and 9th lines, csam sends two bytes of urgent, pushed data to rtsg.
If the snapshot was small enough that tcpdump didn’t capture the full TCP header, it interprets as
much of the header as it can and then reports ‘‘[|tcp]’’ to indicate the remainder could not be
interpreted. If the header contains a bogus option (one with a length that’s either too small or
beyond the end of the header), tcpdump reports it as ‘‘[bad opt]’’ and does not interpret any further
options (since it’s impossible to tell where they start). If the header length indicates options are
present but the IP datagram length is not long enough for the options to actually be there, tcpdump
reports it as ‘‘[bad hdr length]’’.
[S] syn 第一次握手
[S.] ack 第二次握手
[.] ack 第三次握手
09:37:27.651505 IP 180.101.49.12.http > node01.39121: Flags [P.], seq 1:1401, ack 169, win 64240, length 1400
09:37:27.651538 IP node01.39121 > 180.101.49.12.http: Flags [.], ack 1401, win 16800, length 0
09:37:27.652341 IP 180.101.49.12.http > node01.39121: Flags [P.], seq 1401:2782, ack 169, win 64240, length 1381
09:37:27.652358 IP node01.39121 > 180.101.49.12.http: Flags [.], ack 2782, win 19600, length 0
[P] push推送数据，每次服务端给客户端发个数据包
[.] 客户端接收,发送给服务端，确认收到
数据包太大一次发不完，则分批次发送
09:37:27.652940 IP node01.39121 > 180.101.49.12.http: Flags [F.], seq 169, ack 2782, win 19600, length 0
09:37:27.655218 IP 180.101.49.12.http > node01.39121: Flags [.], ack 170, win 64239, length 0
09:37:27.661459 IP 180.101.49.12.http > node01.39121: Flags [FP.], seq 2782, ack 170, win 64239, length 0
09:37:27.661489 IP node01.39121 > 180.101.49.12.http: Flags [.], ack 2783, win 19600, length 0
[F] FIN
[F.]客户端要断开，给服务端发信息
[.]服务端收到信息，确认，给客户端
[FP.]服务端也要断开连接，发送消息给客户端
[.]客户端收到信息，确认给服务端
网卡信息
[root@node01 fd]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=static
IPADDR=192.168.254.11
NETMASK=255.255.255.0
GATEWAY=192.168.254.2
DNS1=114.114.114.114
route -n
route命令输出的路由表字段含义如下
https://blog.csdn.net/u011857683/article/details/83795435?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param
目标ip和子网掩码按位与，得到的网关，去匹配，找到要发送的网关，然后向挖外部网络发送数据
如何验证？
先用arp -d 清理缓存的网关地址 ,可以看到 网关地址192.168.254.2对应的mac 没有了
重新请求百度地址
arp -d 192.168.254.2 && curl www.baidu.com
发现网关的mac有出现了
tcpdump可以看到有个who-has 网关192.168.254.2的request。可以证明确实走了这个网关。然后，返回给一个mac地址，有了这个地址，就接着往下一层物理层发送数据，然后才会建立tcp连接请求。
结论：
对于客户端服务端来说：是tcp 层面。ip +port 方式建立连接沟通
对于底层，是解析后，计算掩码地址，查找mac地址，然后发送给下一跳，记录了，经过几次下一跳，经过电信等网络，连接到了百度的服务器那边。