TCP/IP 学习
2017-07-22 20:28
113 查看
转载自:
http://www.lxxyx.win/2017/04/17/2017/incu/tcpip/
[b]起因[/b]
之前自己学习的时候,碰到一些与计算机网络相关的问题。有侧重于HTTP的,也有侧重于TCP/IP等偏底层知识的。
今天对着阿里的《技术之瞳》这本书,准备系统学习一下计算机科学相关的知识。而书中的重点,就是TCP/IP。
[b]TCP/IP 三次握手和四次挥手[/b]
首先要说的,就是最经典的问题之一,TCP/IP 三次握手和四次挥手。
具体可以看图,内容应该也很直白。
自己在学习过程中,产生的疑点在于三次挥手中的第三次握手。
也就是发送方发送ACK信号这一条。
在自己的理解中,既然已经确认了对方确认了自己的请求,那么自己再发送ACK信号是否是多余的?
后续再继续查阅相关文档时候发现,并不是自己想的那样,《图解TCP/IP》这本书简化了细节但有些时候是也不利于自己的理解。
第一次握手(SYN=1, seq=x):
客户端发送一个 TCP的 SYN 标志位置1的包,指明客户端打算连接的服务器的端口,以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。
发送完毕后,客户端进入 SYN_SEND 状态。
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):
服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号,放到Seq 域里,同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1,即X+1。
发送完毕后,服务器端进入 SYN_RCVD 状态。
第三次握手(ACK=1,ACKnum=y+1)
客户端再次发送确认包(ACK),SYN标志位为0,ACK标志位为1,并且把服务器发来
ACK的序号字段+1,放在确定字段中发送给对方,并且在数据段放写ISN
发送完毕后,客户端进入 ESTABLISHED 状态,当服务器端接收到这个包时,也进入 ESTABLISHED 状态,TCP握手结束。
引用自:TCP三次握手四次挥手
是的,《图解TCP/IP》这本书简化了客户端进入 XXX 状态这一点,所以看得时候是有些云里雾里的。
具体则是:
为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。
“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”
引用自:简析TCP的三次握手与四次分手
[b]确定唯一目标[/b]
在发送数据时,如何确定唯一的发送目标。
之前自己想的是ip地址+MAC地址,后续看书时候发现并不是。
MAC地址很多时候只是充当了下一跳的作用,而非唯一地址。
而确定唯一目标的关键,则在于IP+端口号。
[b]有了 IP 地址,为什么还要用 MAC 地址?[/b]
这个是在看ARP协议时候,产生的问题。
后面发现是因为历史遗留与需要唯一识别的原因。
具体的内容可以看:有了 IP 地址,为什么还要用 MAC 地址?
http://www.lxxyx.win/2017/04/17/2017/incu/tcpip/
[b]起因[/b]
之前自己学习的时候,碰到一些与计算机网络相关的问题。有侧重于HTTP的,也有侧重于TCP/IP等偏底层知识的。
今天对着阿里的《技术之瞳》这本书,准备系统学习一下计算机科学相关的知识。而书中的重点,就是TCP/IP。
[b]TCP/IP 三次握手和四次挥手[/b]
首先要说的,就是最经典的问题之一,TCP/IP 三次握手和四次挥手。
具体可以看图,内容应该也很直白。
自己在学习过程中,产生的疑点在于三次挥手中的第三次握手。
也就是发送方发送ACK信号这一条。
在自己的理解中,既然已经确认了对方确认了自己的请求,那么自己再发送ACK信号是否是多余的?
后续再继续查阅相关文档时候发现,并不是自己想的那样,《图解TCP/IP》这本书简化了细节但有些时候是也不利于自己的理解。
第一次握手(SYN=1, seq=x):
客户端发送一个 TCP的 SYN 标志位置1的包,指明客户端打算连接的服务器的端口,以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。
发送完毕后,客户端进入 SYN_SEND 状态。
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):
服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号,放到Seq 域里,同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1,即X+1。
发送完毕后,服务器端进入 SYN_RCVD 状态。
第三次握手(ACK=1,ACKnum=y+1)
客户端再次发送确认包(ACK),SYN标志位为0,ACK标志位为1,并且把服务器发来
ACK的序号字段+1,放在确定字段中发送给对方,并且在数据段放写ISN
发送完毕后,客户端进入 ESTABLISHED 状态,当服务器端接收到这个包时,也进入 ESTABLISHED 状态,TCP握手结束。
引用自:TCP三次握手四次挥手
是的,《图解TCP/IP》这本书简化了客户端进入 XXX 状态这一点,所以看得时候是有些云里雾里的。
具体则是:
为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。
“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”
引用自:简析TCP的三次握手与四次分手
[b]确定唯一目标[/b]
在发送数据时,如何确定唯一的发送目标。
之前自己想的是ip地址+MAC地址,后续看书时候发现并不是。
MAC地址很多时候只是充当了下一跳的作用,而非唯一地址。
而确定唯一目标的关键,则在于IP+端口号。
[b]有了 IP 地址,为什么还要用 MAC 地址?[/b]
这个是在看ARP协议时候,产生的问题。
后面发现是因为历史遗留与需要唯一识别的原因。
具体的内容可以看:有了 IP 地址,为什么还要用 MAC 地址?
相关文章推荐
- webService学习5:Eclipse的TCP/IP工具
- 《TCP-IP详解 卷2:实现》学习笔记—接口层分析
- TCP/IP学习之 TCP拥塞控制与定时器
- JAVA基础 day25 网络编程 IP类 UDP,TCP传输学习 简易聊天工具 TCP并发学习
- TCP/IP详解--学习笔记(9)-TCP协议概述
- ASP.NET MVC WebApi 返回数据类型序列化控制(json,xml) 用javascript在客户端删除某一个cookie键值对 input点击链接另一个页面,各种操作。 C# 往线程里传参数的方法总结 TCP/IP 协议 用C#+Selenium+ChromeDriver 生成我的咕咚跑步路线地图 (转)值得学习百度开源70+项目
- 【学习笔记:0】TCP-IP详解卷一:协议
- TCP/IP 协议状态学习
- (原创)TCP-IP学习笔记之UDP(用户数据报协议)
- TCP/IP学习 1.3IPV4地址
- TCP/IP学习(四)TCP缓冲区大小及限制
- Linux学习笔记 - TCP/IP 是如何運作的
- TCP/IP学习(一) -- 网络分层(OSI分层和TCP/IP分层)
- TCP-IP详解学习(一)
- TCP/IP学习(30)——L2数据链路层的数据包处理详细流程
- Windows Sockets 学习笔记 [第2章 TCP/IP]
- 转载 TCPIP学习笔记之概述
- TCP/IP 学习笔记(二)
- TCP-IP学习笔记(八)——RARP:逆地址解析协议
- Java学习之网路编程--TCP/IP