MisakaOJ | 第二次记录

MisakaOJ项目，第一次记录内容



### 1 建表

1. 题目表
    - identity，varchar，长度36，作为题目的唯一标识
    - cid，varchar，长度255，作为题目的分类
    - title，varchar，长度255，作为题目的标题
    - content，varchar，长度255，作为题目的正文
    - max_runtime，int，长度11，题目最大运行时间
    - max_memory，int，长度11，题目最大运行内存

``` go
type Question struct {
	gorm.Model
	Identity   string `gorm:"column:identity;type:varchar(36);" json:"identity"`        // 题目唯一标识
	CategoryId string `gorm:"column:category_id;type:varchar(255);" json:"category_id"` // 分类ID 以逗号分割
	Title      string `gorm:"column:title;type:varchar(255);" json:"title"`             // 题目标题
	Content    string `gorm:"column:content;type:text;" json:"content"`                 // 题目正文
	MaxRuntime int    `gorm:"column:max_runtime;type:int(11)" json:"max_runtime"`       // 最大运行时长
	MaxMem     int    `gorm:"column:max_memory;type:int(11)" json:"max_mem"`            // 最大允许内存
}

func (table *Question) TableName() string {
	return "question"
}
```

2. 用户表
    - identity，varchar，长度36，唯一标识
    - name，varchar，长度100，用户名
    - password，varchar，长度32，用户密码，md5加密
    - phone，varchar，长度20，用户手机号
    - mail，varchar，长度100，用户邮箱

``` go
type User struct {
	gorm.Model
	Identity string `gorm:"column:identity;type:varchar(36);" json:"identity"` // 用户唯一标识
	Name     string `gorm:"column:user;type:varchar(100);" json:"name"`        // 用户名
	Password string `gorm:"column:password;type:varchar(32);" json:"password"` // 密码 加密后
	Phone    string `gorm:"column:phone;type:varchar(20)" json:"phone"`        // 手机号
	Mail     string `gorm:"column:mail;type:varchar(100);" json:"mail"`        // 邮箱地址
}

func (table *User) TableName() string {
	return "user"
}
```

3. 分类表
    - identity，varchar，长度36，唯一标识
    - name，varchar，长度100，分类名称
    - parent_id，int，长度11，父级id，自身为顶级时默认为0

``` go
type Category struct {
	gorm.Model
	Identity string `gorm:"column:identity;type:varchar(36);" json:"identity"`        // 分类唯一标识
	Name     string `gorm:"column:user;type:varchar(100);" json:"name"`               // 分类名称
	ParentId int    `gorm:"column:parent_id;type:int(11);default:0" json:"parent_id"` // 父级ID 自身为顶级是默认为0
}

func (table *Category) TableName() string {
	return "category"
}
```

4. 提交记录表
    - identity，varchar，长度36，唯一标识
    - problem_identity，varchar，长度36，问题唯一标识
    - user_identity，varchar，长度36，用户唯一标识
    - path，varchar，长度255，代码保存位置路径
    - status，tinyint，长度1，提交记录状态，默认为0待判断，1为答案正确，2为答案错误，3运行超时，4运行超过最大内存

``` go
type Submit struct {
	gorm.Model
	Identity        string `gorm:"column:identity;type:varchar(36);" json:"identity"`                 // 提交记录唯一标识
	ProblemIdentity string `gorm:"column:problem_identity;type:varchar(36);" json:"problem_identity"` // 问题唯一标识
	UserIdentity    string `gorm:"column:user_identity;type:varchar(36);" json:"user_identity"`       // 用户唯一标识
	Path            string `gorm:"column:path;type:varchar(255);" json:"path"`                        // 保存提交代码位置的路径
	Status          int    `gorm:"column:status;type:tinyint(1);default:0;" json:"status"`            // 提交记录状态
}

func (table *Submit) TableName() string {
	return "submit"
}
```

### 2 Swagger-Gin使用

**安装**：

``` bash
go get -u github.com/swaggo/gin-swagger
go install github.com/swaggo/swag/cmd/swag@latest
go get -u github.com/swaggo/files
```

**使用**：

1. 命令行输入`swag init`即可在该位置下快速生成/更新docs包以及其中的文件
2. 命令行输入`swag -v`查看swag版本号
3. 在gin的路由器上加入swagger：`r.GET("/swagger/*any", ginSwagger.WrapHandler(swaggerFiles.Handler))`，并且在include中以匿名方式加入刚才生成的docs包。URL路径可以自己指定。
4. 运行即可在`xxxxx/swagger/index.html`下访问Swagger文档。

**为一个接口编写注释以快速生成Swagger**：

假设现在有这么一个接口：

``` go
func GetQuestionList(c *gin.Context) {
	page, err := strconv.Atoi(c.DefaultQuery("page", constants.DefaultPage))
	if err != nil {
		log.Println("Get Param Error: ", err)
		return
	}
	size, err := strconv.Atoi(c.DefaultQuery("size", constants.DefaultSize))
	if err != nil {
		log.Println("Get Param Error: ", err)
		return
	}
	keyword := c.Query("keyword")
	// 中间省略
	c.JSON(http.StatusOK, gin.H{
		"code": 200,
		"data": gin.H{
			"list":  result,
			"count": count,
		},
	})
}
```

为其添加注解可以帮助Swagger-Gin快速生成文档，比如：

``` go
// @Tags 公共方法
// @Summary 获取问题列表
// @Param page query int false "page"
// @Param size query int false "size"
// @Param keyword query string false "keyword"
// @Success 200 {data} json "{"code": "200", "data": ""}"
// @Router /question-list [get]
func GetQuestionList(c *gin.Context) {
	page, err := strconv.Atoi(c.DefaultQuery("page", constants.DefaultPage))
	if err != nil {
		log.Println("Get Param Error: ", err)
		return
	}
	size, err := strconv.Atoi(c.DefaultQuery("size", constants.DefaultSize))
	if err != nil {
		log.Println("Get Param Error: ", err)
		return
	}
	keyword := c.Query("keyword")
	// 中间省略
	c.JSON(http.StatusOK, gin.H{
		"code": 200,
		"data": gin.H{
			"list":  result,
			"count": count,
		},
	})
}
```

可以通过注解被添加到文档中的信息有以下类别：

| 注解 | 含义 | 示例 |
| --- | --- | --- |
| description | 该接口的详细说明 | @Description xxx |
| tags | 该接口的类别 | @Tags xxx |
| summary | 该接口的简短说明 | @Summary xxx |
| accept | 该接口接受数据类型 | @Accept json |
| produce | 该接口返回的数据的类型 | @Produce json |
| param | 该接口的参数 这个注解可以有多行 每一行代表一种参数 | @Param 参数名 参数类型 数据类型 是否必须 注释 属性（可选） |
| success | 该接口成功返回的结果 | @Success 返回码 {参数类型} 数据类型 注释 |
| failure | 该接口失败返回的结果 | 同success |
| response | 该接口返回结果说明 | 同success |
| router | 该接口的路径 | @Router xxx |

更多信息可以查看[官方文档](https://github.com/swaggo/swag?tab=readme-ov-file#general-api-info)

### 3 获取题目列表

``` go
// GetQuestionList
// @Tags 公共方法
// @Summary 获取问题列表
// @Param page query int false "page"
// @Param size query int false "size"
// @Param keyword query string false "keyword"
// @Success 200 {data} json "{"code": "200", "data": ""}"
// @Router /question-list [get]
func GetQuestionList(c *gin.Context) {
	page, err := strconv.Atoi(c.DefaultQuery("page", constants.DefaultPage))
	if err != nil {
		log.Println("Get Param Error: ", err)
		return
	}
	size, err := strconv.Atoi(c.DefaultQuery("size", constants.DefaultSize))
	if err != nil {
		log.Println("Get Param Error: ", err)
		return
	}
	page = (page - 1) * size // page到offset的转换
	keyword := c.Query("keyword")
	var count int64
	
	// tx是transaction的缩写
	tx := models.GetQuestionList(keyword)
	result := make([]*models.Question, 0)
	err = tx.Count(&count).Omit("content").Offset(page).Limit(size).Find(&result).Error
        // Omit 指定一行要忽略的数据
	if err != nil {
		log.Println("Get Problem List Error: ", err)
		return
	}
	c.JSON(http.StatusOK, gin.H{
		"code": 200,
		"data": gin.H{
			"list":  result,
			"count": count,
		},
	})
}

func GetQuestionList(keyword string) *gorm.DB {
	return DB.Model(new(Question)).Where("title like ? OR content like ?", "%"+keyword+"%", "%"+keyword+"%")
}
```

MisakaOJ | 第一次记录

随笔 or 瞎写 1

题目：

1. TCP连接三次握手的过程，为什么是三次，可以是两次或者更多吗？
2. TCP四次挥手的过程，为什么是四次？
3. HTTP的Keep-Alive是什么？TCP的KeepAlive和HTTP的Keep-Alive是一个东西吗？



### 1 TCP的三次握手

TCP是面向连接的协议，它确保了双方所收发的数据的正确和有序性。在利用TCP收发数据之前，必须通过双端的三个报文，即“三次握手”来确保连接的建立。这三个报文分别是：（想要建立连接的一端为A，另一端为B）

- A向B发送的`SYN`报文
- B向A发送的`SYN+ACK`报文
- A向B发送的`ACK`报文

通信两端状态变化如下：

1. A向B发送`SYN`报文之前，A处于`CLOSE`状态，B处于`LISTEN`状态。A会初始化序号`client_isn`，并将其置于`SYN`报文的序列号中，并将其发送给B，示意A准备和B建立连接。发送完成后A处于`SYN_SENT`状态。
2. B收到A发送的`SYN`报文之后，B也会初始化自己的序列号`server_isn`并置于准备回复给客户端的`SYN+ACK`报文的序列号字段中；同时，确认应答号字段为A的`client_isn + 1`。最后将该`SYN+ACK`报文发送给A。此后B进入`SYN_RCVD`状态。
3. A收到B的`SYN+ACK`报文后，会回复B`ACK`报文，该报文内的确认序列号为B的`server_isn + 1`，**这次报文可以携带要传输的数据**，此后客户端进入`ESTABLISHED`状态。
4. B收到A的`ACK`报文后，也进入`ESTABLISHED`状态。

![image.png](https://www.misaka19327.cc/static/img/b80e40d137a77049a5e740042653b85f.image.png)

这三次握手的最主要目的：

1. 同步序列号
2. 第一次握手+第二次握手使通信双方都能确保A到B的收发能力
3. 第二次握手+第三次握手使通信双方都能确保B到A的收发能力

### 2 TCP的四次挥手

和三次握手相对的，即为断开连接时的四次挥手过程。它通过通信两端的四个报文来确保连接正确的断开。这四个报文分别是：（想要断开连接的一端为A，另一端为B）

- A向B发送的`FIN`报文
- B向A发送的`ACK`报文
- A向B发送的`FIN`报文
- B向A发送的`ACK`报文

通信两端状态变化如下：

1. 在四次挥手之前，通信两端都处于`ESTABLISHED`状态。
2. A想要关闭连接，就先发送`FIN`报文过去，同时自己进入`FIN_WAIT_1`状态。
3. B收到该报文之后，就立即向A发送`ACK`应答报文，同时自己进入`CLOSED_WAIT`状态。
4. A收到B发送的报文之后，自身进入`FIN_WAIT_2`状态。
5. B发送完自己想要发送的数据之后，也会向客户端发送`FIN`报文，同时自己进入`LAST_ACK`状态。
6. A收到来自B的报文之后，立即向B发送`ACK`报文，同时自己进入`TIME_WAIT`状态。在该状态下经过两个`MSL`时间段之后，如果没有报文到达，就自动进入`CLOSE`状态，完成了连接的关闭。
7. B收到来自A的报文之后，进入`CLOSE`状态，完成了连接的关闭。

这四次挥手的主要目的：

1. 第一次表示A不再发送数据，但是还能接受来自B的数据。
2. 第三次挥手表示B也不再发送数据，这时发送`FIN`才表示同意关闭连接。

客户端和服务端这几个状态的具体行为：

- `FIN_WAIT_1`：该状态下，A会一直等待B发送的应答报文，如果等待超时就重传，直到收到应答报文或者超出重传次数。如果超出重传次数就直接关闭连接。
- `CLOSE_WAIT`：**应答报文是不会重传的**，因此该状态下，如果这个应答报文没有抵达A，那么A会重传`FIN`报文，B依然会发送应答报文。在该状态下，B会继续发送原本要发送的数据，直到B的数据全部发送完毕，用户态调用`close`进入下一个状态。
- `LAST_ACK`：B在`CLOSE_WAIT`状态下，B的用户进程调用`close`进入该状态。B首先会发出一个`FIN`报文，并且在该状态下等待A的确认报文。如果收到了来自A的确认报文，则关闭连接；如果超时则与A的`FIN_WAIT_1`状态下的重传机制相同。
- `FIN_WAIT_2`：A在收到B对第一次挥手的确认报文之后进入该状态。在该状态下，如果A的用户进程调用的是`close`函数来关闭连接的话，该状态持续`tcp_fin_timeout`时间之后自动关闭连接；如果A的用户进程调用的是`shutdown`函数来关闭连接的话，该状态会一直持续到收到B的第三次挥手报文。
- `TIME_WAIT`：A在收到B的第三次挥手报文后进入该状态。在该状态下A会先发送确认报文过去，之后经过两个`MSL`时间段之后，如果没有报文到达，就自动进入`CLOSE`状态。

> `MSL`（Maximum Segment Lifetime）：报文最大生存时间，它是任何网络报文在网络上存在的最长时间。**注意`TTL`的单位是路由器跳数，而`MSL`的单位是时间**。默认情况下，Linux的`MSL`是30秒。两个`MSL`时间段，正好是报文一去一回的时间。

![image.png](https://www.misaka19327.cc/static/img/a1a31d4d4d8c94292af82c19f821de1f.image.png)

### 3 题目一

:::info{title="题目"}
TCP连接三次握手的过程，为什么是三次，可以是两次或者更多吗？
:::

**不可以**。

原因一：**两次握手就建立连接的话，不可能同时保证通信两端的收发能力**。在第二次握手后，即使假设这两次握手的报文都能正确抵达目的地，那么在客户端的视角，能够确保了客户端的收发能力（第一次握手发出去，在第二次握手收到回应）和服务端的收发能力（第一次握手收到报文，第二次握手发送报文），但是在服务端的视角，是不能确认客户端的收信能力的。如果客户端在收到第二次握手之前就放弃建立连接，那么服务器就是在和一个不存在的客户端建立连接，浪费了服务器的资源。

原因二：**避免历史连接**。如果在第二次握手后，服务端就直接建立连接，那么服务端就没有机会确定要建立的连接的序列号是否正确，从而浪费资源。比如说客A户端在发送初始化`client_isn`为90之后发送`SYN`报文，之后在该报文还未抵达服务端时，客户端由于某种原因宕机并且马上恢复，再次初始化`client_isn`为100之后发送`SYN`报文，那么服务器要响应的就是这两个序列号不同的`SYN`报文。按照假设，服务端收到第一个`SYN`报文之后马上建立连接，那么通信两端的序列号就会出现不一致的情况，服务器不得不取消连接之后重新根据第二个`SYN`报文建立连接，如此就会出现资源的浪费。

![image.png](https://www.misaka19327.cc/static/img/23fb951f748dd5a6690a98b383ba6c31.image.png)

这两个原因总结下来只有一个关键问题：**TCP建立连接的三次握手，目的是确保通信两端的收发能力，并且同步序列号，窗口大小等信息**。如果少了任何一次握手，这两个目的都不能完成。第一个目的对应原因一，第二个目的对应原因二。如果不能保证这些就去建立连接，就有可能会导致资源的浪费。

至于为什么不能是四次握手，倒也不是说不能是四次，而是**三次握手就能解决的问题，四次握手无异于浪费资源**。

### 3 题目二

:::info{title="题目"}
TCP四次挥手的过程，为什么是四次？
:::

首先先排除五次以上的可能性，既然四次已经跑的很好了，就没必要再多发报文了。

其次，这四次挥手，每个挥手都有自己独特的作用：前两次挥手确认主动断开那一端不再发送报文，后两次挥手确认被动断开那一端不再发送报文。如果想要降低挥手次数，无非两种方案：合并第二、三次挥手；或者取消第四次挥手。

先说第一种：合并第二、三次挥手，在以下条件下是成立的：即通信两端都没有开启`TCP_QUICKACK`，同时被动关闭连接方确实没有后续数据要发送，则第二、三次挥手会被合并为一个报文。