计算机网络基础复习篇三

【写在前面】 本篇完全为个人的笔记，对于计算机网络希望大家学习
计算机组网 http图解 tcp图解 和 tcpip编程。在编程中把学习的知识内化，本篇笔记比较适合面试~

一 传输层的协议主要有哪些

TCP 和 UDP

二 tcp协议详细叙述

TCP:
1 tcp的特点:
面向连接的 可靠的传输 双工通信 以字节流为传输结构 有序的传输

2 以tcp为底层的应用层协议有哪些
1 http 端口号80 https 端口号443 smtp，ftp telnet

3 tcp的流量控制
tcp的流量控制是使用滑动窗口机制，目的是让发送端和接收端的窗口发送最大数据量保持稳定

1 我们首先要了解，我们TCP数据发送的工作过程：
1发送端和接收端建立连接后，TCP协议是发送数据，接收确认信号，再发送数据，再返回确认信号，但是这样的吞吐量就很低，假如没收到确认还要不停重传，并且要等待确认的返回；相当于顺序返回等待工作，效率太低。
2 所以就有了发送端和接收端各自维护一个滑动窗口，发送端和接收端说窗口是5段，接收端说太大了，3段；那此时发送端就会调节连续发送3段数据（0-3000）再等待接收端回写确认数据3001，而不需要等待回写信号1001 我们就认为前面的数据已经收到了（因为咱们tcp是可靠的）；这个时候窗口就变成了从3001–6000，发送端继续发送数据
3 这样循环反复的时候发现接收端那边缓冲区已经满了，不能接收数据了。为了能够反复确认，每隔一段时间，发送端就会发送1字节的数据向接收端询问窗口的大小，收到窗口大小回复之后才会继续
4 但是还有一种特殊情况，假如在0-3000的时候，发送端发送0-1000断掉了，1001-3000是正常的，那因为TCP的整个收包是有序的，接收端就会不停重发我没收到1001的确认，我没收到1001 的确认，我没收到1001的确认
连续3次ack确认，我们就认为是发生了网络故障，会进行重传

图如下，图片是截图TCPIP详解书籍的

4 tcp的拥塞控制
拥塞控制是控制网络之间负载和吞吐量的bug

1 慢启动：cwnd窗口阈值
每当收到一个ACK，cwnd++; 呈线性上升
每当过了一个RTT，cwnd = cwnd*2; 呈指数让升

2 拥塞避免：到达阈值 采用拥塞避免
每当收到一个ACK，cwnd = cwnd + 1/cwnd
每当过了一个RTT，cwnd = cwnd + 1

3 快重传：
在收到3个duplicate ACK时就开启重传，而不用等到RTO超时
sshthresh = cwnd = cwnd /2
cwnd 重置为 1
进入快速恢复算法——Fast Recovery

4 快恢复：
至少收到了3个Duplicated Acks，说明网络也不那么糟糕，可以快速恢复。
cwnd = sshthresh + 3 * MSS （3的意思是确认有3个数据包被收到了）
重传Duplicated ACKs指定的数据包
如果再收到 duplicated Acks，那么cwnd = cwnd +1
如果收到了新的Ack，那么，cwnd = sshthresh ，然后就进入了拥塞避免的算法了。

4.1 为什么快速重传是3次ack确认

经验所得
tcp是三次握手建立连接
两次duplicated ACK时很可能是乱序造成的！三次duplicated ACK时很可能是丢包造成的！四次duplicated ACK更更更可能是丢包造成的！但是这样的响应策略太慢。丢包肯定会造成三次duplicated ACK!综上是选择收到三个重复确认时窗口减半效果最好，这是实践经验。

5 tcp的三次握手和四次挥手
5.1 三次握手过程

1 客户端处于关闭状态，服务端处于监听状态listen
2 客户端发起syn数据包，发送seq=x，ack=1 的数据包给服务器，此时客户端变为等待确认状态
3 服务端接收到客户端发出的syn请求连接，向客户端发送ack确认信号：seq=y ACK=x
4 客户端接收到服务端发送的确认信号，再发一个syn告诉服务端我已经收到了你的信号，seq=x+1， ACK= y
在编程中，我们的客户端发起connect就是调用tcp三次握手的过程

5.2 四次挥手过程

1 客户端发起FIN报文，ack=1，fin=x告诉服务器我的数据发送完了我要准备关闭连接了
2 服务端接收到fin报文，回写确认信号ACK=x,FIN =y，告诉客户端我接收到你的关闭申请
3 服务器还能发送数据，等待服务端数据发送完毕之后，会向客户端发送FIN报文，告诉客户端，我数据发送完毕了，我也准备关闭了
4 客户端接收到服务端发送的FIN报文，知道服务端数据发送完毕了，可以准备关闭，就回写一个确认信号，并等待2ML 关机。

6 为什么是三次握手详细说说

第一次握手是客户端向服务端发起连接，告诉服务端我要连接发数据了
第二次握手是服务端告诉客户端，我能收到你的信号并且能发送信号给你，这个时候服务端只知道客户端能发送，但是不知道客户端是否能接收
第三次握手是客户端告诉服务端我能接收信号，第三次发送的数据可以携带其他的数据内容。
三次握手可以避免服务端无端等待的过程，减少资源的占用

7 为什么是四次挥手

四次挥手的原因：每次挥手智能发送一个FIN报文，对方收到报文需要先回一个确认，只有当服务端发送完毕了，才会向客户端发送FIN报文告诉客户端准备关闭，客户端在回写确认报文

8 为什么等待2ml

TIME_WAIT状态也成为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime），它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。
对一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）。
这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用

9 关于tcp的沾包和拆包是什么

一个完整的业务可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这个就是TCP的拆包和粘包问题

由TCP连接复用造成的粘包问题。
因为TCP默认会使用Nagle算法，此算法会导致粘包问题。
只有上一个分组得到确认，才会发送下一个分组；
收集多个小分组，在一个确认到来时一起发送。
数据包过大造成的粘包问题。
流量控制，拥塞控制也可能导致粘包。
接收方不及时接收缓冲区的包，造成多个包接收

解决方法：
Nagle算法问题导致的，需要结合应用场景适当关闭该算法
尾部标记序列。通过特殊标识符表示数据包的边界，例如\n\r，\t，或者一些隐藏字符。
头部标记分步接收。在TCP报文的头部加上表示数据长度。
应用层发送数据时定长发送

10 说说tcp的报文结构构成

这里是引用

三 udp协议详细叙述

1 udp的特点
udp是面向无连接的 尽最大努力交付 无序的传输协议

2 使用udp为底层的应用层有哪些
DNS
RIP

四 syn攻击

1 什么是syn攻击
洪范攻击，大量无源的虚拟ip地址同时向服务器发起tcp连接，导致服务器不停的超时重传确认

2 怎么识别和避免
一般有很多无源的虚拟ip同时发起 就是syn攻击
在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击

netstat -n -p TCP | grep SYN_RECV

1 设置最大重传数目 设置超时时间
2 防火墙过滤一些ip地址
3 增大最大半连接数
4 SYN cookies技术（cookies是啥呢 缓存类似）

五 tcpip网络编程懂吗（这个建议看看tcpip编程 自己敲一遍代码哈 讲的蛮好~）

1 我也正在总结ing 自己边看书边敲代码，源码可以私信我拿，太多了不好放上去

我这边简单说下linux下的思路

linux下的套接字编程socket函数

1 服务端：

先申请socket套接字，类似于你打电话插上了电缆，socket要指定参数1协议簇：IPV4或者IPV6;指定参数2：传输方式：流传输； 指定参数三：具体协议，默认0为tcp

2 bind()函数

3 服务器进入监听状态
listen()函数

4 服务端进入accept函数 拥塞状态，等待客户端发连接通信

6 服务端可以向客户端传输数据 使用write函数

2 客户端

1 客户端发起socket编程

2 客户端使用connect函数和服务端连接（connect函数相当于tcp的三次握手）

3 客户端向服务读取数据read函数

总：最后使用完毕都要关闭close()函数关闭连接