Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Commit 12e742c

Browse files
tcp面试题整理
1 parent 0418716 commit 12e742c

File tree

4 files changed

+32
-8
lines changed

4 files changed

+32
-8
lines changed

‎docs/advance/distributed/4-micro-service.md‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -88,6 +88,8 @@ head:
8888

8989
**1、RPC**
9090

91+
远程过程调用,简单的理解是一个节点请求另一个节点提供的服务。
92+
9193
优点:简单,常见。因为没有中间件代理,系统更简单
9294

9395
缺点:

‎docs/advance/system-design/2-order-timeout-auto-cancel.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -652,8 +652,8 @@ lRabbitMQ 的 Queue 可以配置 x-dead-letter-exchange 和 x-dead-letter-routin
652652

653653
最后给大家分享一个Github仓库,上面有大彬整理的**300多本经典的计算机书籍PDF**,包括**C语言、C++、Java、Python、前端、数据库、操作系统、计算机网络、数据结构和算法、机器学习、编程人生**等,可以star一下,下次找书直接在上面搜索,仓库持续更新中~
654654

655-
![](http://img.dabin-coder.cn/image/Image.png)
655+
![](http://img.topjavaer.cn/image/Image.png)
656656

657-
![](http://img.dabin-coder.cn/image/image-20221030094126118.png)
657+
![](http://img.topjavaer.cn/image/image-20221030094126118.png)
658658

659659
**Github地址**:https://github.com/Tyson0314/java-books

‎docs/computer-basic/tcp.md‎

Lines changed: 26 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -44,6 +44,12 @@ IP 层是「不可靠」的,它不保证网络包的交付、不保证网络包
4444

4545
因为当Server端收到Client端的`SYN`连接请求报文后,可以直接发送`SYN+ACK`报文。**但是在关闭连接时,当Server端收到Client端发出的连接释放报文时,很可能并不会立即关闭SOCKET**,所以Server端先回复一个`ACK`报文,告诉Client端我收到你的连接释放报文了。只有等到Server端所有的报文都发送完了,这时Server端才能发送连接释放报文,之后两边才会真正的断开连接。故需要四次挥手。
4646

47+
## SIN/FIN不包含数据却要消耗序列号
48+
49+
凡是需要对端确认的,一定消耗TCP报文的序列号。SYN和FIN需要对端的确认,因此需要消耗一个序列号。
50+
51+
SYN作为三次握手的确认。FIN作为四次挥手的确认。如果没有序列号,会导致SYN请求多次重发,服务端多次处理,造成资源浪费
52+
4753
## 说说TCP报文首部有哪些字段,其作用又分别是什么?
4854

4955
![](http://img.topjavaer.cn/img/tcp报文.png)
@@ -109,9 +115,17 @@ TCP是面向流,没有界限的一串数据。TCP底层并不了解上层业
109115

110116
## 说说TCP是如何确保可靠性的呢?
111117

112-
- 首先,TCP的连接是基于**三次握手**,而断开则是基于**四次挥手**。确保连接和断开的可靠性。
113-
- 其次,TCP的可靠性,还体现在**有状态**;TCP会记录哪些数据发送了,哪些数据被接收了,哪些没有被接受,并且保证数据包按序到达,保证数据传输不出差错。
114-
- 再次,TCP的可靠性,还体现在**可控制**。它有数据包校验、ACK应答、**超时重传(发送方)**、失序数据重传(接收方)、丢弃重复数据、流量控制(滑动窗口)和拥塞控制等机制。
118+
- TCP的连接是基于**三次握手**,而断开则是基于**四次挥手**。确保连接和断开的可靠性。
119+
- TCP的可靠性,还体现在**有状态**。TCP会记录哪些数据发送了,哪些数据被接收了,哪些没有被接受,并且保证数据包按序到达,保证数据传输不出差错。
120+
- 确认和重传机制:建立连接时三次握手同步双方的"序列号 + 确认号 + 窗口大小信息",是确认重传、流控的基础。传输过程中,如果Checksum校验失败、丢包或延时,发送端重传
121+
- 流量控制:窗口和计时器的使用。TCP窗口中会指明双方能够发送接收的最大数据量
122+
- 拥塞控制
123+
124+
## TCP的重传机制是什么?
125+
126+
由于TCP的下层网络(网络层)可能出现丢失、重复或失序的情况,TCP协议提供可靠数据传输服务。为保证数据传输的正确性,TCP会重传其认为已丢失(包括报文中的比特错误)的包。TCP使用两套独立的机制来完成重传,一是基于时间,二是基于确认信息。
127+
128+
TCP在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送数据的ACK确认报文,则对该报文进行重传,在达到一定次数还没有成功时放弃并发送一个复位信号。
115129

116130
## 说下TCP的滑动窗口机制
117131

@@ -170,4 +184,12 @@ TCP 四元组可以唯一的确定一个连接,四元组包括如下: 源地址
170184

171185
源地址和目的地址的字段(32位)是在 IP 头部中,作用是通过 IP 协议发送报文给对方主机。
172186

173-
源端口和目的端口的字段(16位)是在 TCP 头部中,作用是告诉 TCP 协议应该把报文发给哪个进程。
187+
源端口和目的端口的字段(16位)是在 TCP 头部中,作用是告诉 TCP 协议应该把报文发给哪个进程。
188+
189+
## 说说TCP KeepAlive 的基本原理?
190+
191+
TCP 的连接,实际上是一种纯软件层面的概念,在物理层面并没有"连接"这种概念。TCP 通信双方建立交互的连接,但是并不是一直存在数据交互,有些连接会在数据交互完毕后,主动释放连接,而有些不会。在长时间无数据交互的时间段内,交互双方都有可能出现掉电、死机、异常重启等各种意外,当这些意外发生之后,这些 TCP 连接并未来得及正常释放,在软件层面上,连接的另一方并不知道对端的情况,它会一直维护这个连接,长时间的积累会导致非常多的半打开连接,造成端系统资源的消耗和浪费,为了解决这个问题,在传输层可以利用 TCP 的 KeepAlive 机制实现来实现。主流的操作系统基本都在内核里支持了这个特性。
192+
193+
TCP KeepAlive 的基本原理是,隔一段时间给连接对端发送一个探测包,如果收到对方回应的 ACK,则认为连接还是存活的,在超过一定重试次数之后还是没有收到对方的回应,则丢弃该 TCP 连接。
194+
195+
> 参考链接:https://hit-alibaba.github.io/interview/basic/network/TCP.html

‎docs/framework/springcloud-interview.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -193,15 +193,15 @@ Spring Boot是Spring推出用于解决传统框架配置文件冗余,装配组
193193

194194
## 18、说说微服务之间是如何独立通讯的?
195195

196-
#### 远程过程调用(Remote Procedure Invocation)
196+
**远程过程调用(Remote Procedure Invocation)**
197197

198198
也就是我们常说的服务的注册与发现,直接通过远程过程调用来访问别的service。
199199

200200
**优点**:简单,常见,因为没有中间件代理,系统更简单
201201

202202
**缺点**:只支持请求/响应的模式,不支持别的,比如通知、请求/异步响应、发布/订阅、发布/异步响应,降低了可用性,因为客户端和服务端在请求过程中必须都是可用的。
203203

204-
#### 消息
204+
**消息**
205205

206206
使用异步消息来做服务间通信。服务间通过消息管道来交换消息,从而通信。
207207

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /