Socket listen() backlog 是什么?

listen() backlog 是什么?

1. Linux 服务器上的一些程序会监听特定端口.

2. 当有 client 连接到服务器的相应端口,进行完 tcp 三次握手之后,相应的连接会放到服务器相应 socket 的队列,等待服务器的应用程序调用 accept() 来读取这个连接;

3. 这个队列的长度,就是 listen() backlog.

以 apache httpd 为例。

1. httpd 会监听 80 端口;

2. 当有用户端连接到服务器的 80 端口,首先会进行 tcp 的三次握手。进行完三次握手后,这个连接会被放到 80 端口这个 socket 的队列里,等待 httpd 去获取这个连接;

3. httpd 随后会调用 accept() 来获取这个连接。这个连接被获取之后,会从这个队列里移除;

4. 这个监听 80 端口的 socket 对应的队列长度,就是 listen() backlog.
继续阅读“Socket listen() backlog 是什么?”

如何使用 Linux 中的 TCP keepalive?

tcp-keepalive 是什么

1. tcp-keepalive,顾名思义,它可以尽量让 TCP 连接“活着”,或者让一些对方无响应的 TCP 连接“宣告死亡”。

2. 一些特定环境,防火墙会自动断开长期无活动的 TCP 连接,tcp-keepalive 可以在连接无活动一段时间后,发送一个空 ack,使 TCP 连接不会被防火墙关闭。

3. 一些时候,对方的服务器可能出现宕机或者网络中断等问题, tcp-keepalive 可以帮助断开这些无响应的连接。

4. tcp-keepalive 需要在应用程序层面针对其所用到的 Socket 进行开启。操作系统层面无法强制所有 socket 启用 tcp-keepalive. (本文在 CentOS/RHEL 6/7 环境进行测试)

继续阅读“如何使用 Linux 中的 TCP keepalive?”

微信/支付宝的条码支付是如何验证账户的?安全吗?

请留意:本文所述的方法仅是经过资料收集和讨论所提出的一种原理假设,并非微信/支付宝官方披露的具体方法。

疑问

在信息时代,路边摊都能接受支付宝付款。于是,我一直有个疑问。

1. 微信/支付宝/Paypal 的条形码支付/二维码支付是如何实现的?它们安全吗?

2. 为什么用户不需要联网,也能完成支付?

条形码/二维码支付的特点

二维码支付主要有“用户扫码”和“商家扫码”(反扫)两种。“用户扫码”是商家提供二维码,用户手机客户端扫码,确认购物信息后进行支付。“商家扫码”(“刷卡支付”)则是用户出示二维码,商户扫描该二维码进行扣款。

“用户扫码”的二维码实际是个购物网站的链接,扫描后的流程与我们通常的网上购物差异不大。

“商家扫码”(“刷卡支付”)则是由用户的手机客户端生成一串“支付码”(如下图),商家读取支付码后,交由支付网关进行清算。据观察,它有如下特点:

1. 用户的手机客户端不需要联网,即可生成支付码并完成交易(第一次使用时,需要联网验证支付密码,来开启扫码支付功能);

2. 这串18位的支付码是动态变化的,大约30秒动态变化一次。

本文将探讨“商家扫码”(“刷卡支付”)背后的原理。

1600126017

继续阅读“微信/支付宝的条码支付是如何验证账户的?安全吗?”

umask 怎样影响新建文件的权限?

1. umask 设置的不是默认权限,而是针对新建文件的一种权限限制。

2. 应用程序在创建文件时,会指定文件的权限 (mode)。而最终这个新建的文件的权限会是 (mode & ~umask).

# man 2 open

O_CREAT
    If  the  file does not exist it will be created.  The owner (user ID) of the file is set to the effective user ID of the process.  The group
    ownership (group ID) is set either to the effective group ID of the process or to the group ID of the parent directory  (depending  on  file
    system  type and mount options, and the mode of the parent directory, see the mount options bsdgroups and sysvgroups described in mount(8)).

    mode specifies the permissions to use in case a new file is created.  This argument must be supplied when O_CREAT is specified in flags;  if
    O_CREAT is not specified, then mode is ignored.  The effective permissions are modified by the process’s umask in the usual way: The permis-
    sions of the created file are (mode & ~umask).  Note that this mode only applies to future accesses of the newly created  file;  the  open()
    call that creates a read-only file may well return a read/write file descriptor.

继续阅读“umask 怎样影响新建文件的权限?”