[root@localhost ~]# hwclock --debug
hwclock from util-linux-2.13-pre7
hwclock: Open of /dev/rtc failed, errno=19: No such device.
No usable clock interface found.
Cannot access the Hardware Clock via any known method.
但是有的能够直接读写I/O，这样虽然/dev/rtc是错的，但还能正常运行
12345
[root@localhost ~]# hwclock --debug
hwclock from util-linux-2.13-pre7
hwclock: Open of /dev/rtc failed, errno=19: No such device.
Using direct I/O instructions to ISA clock.
.....
url_effective The URL that was fetched last. This is most meaningful if you’ve told curl to follow location: headers.
filename_effective The ultimate filename that curl writes out to. This is only meaningful if curl is told to write to a file with the –remote-name or –output option. It’s most useful in combination with the –remote-header-name option. (Added in 7.25.1)
http_code http状态码，如200成功,301转向,404未找到,500服务器错误等。(The numerical response code that was found in the last retrieved HTTP(S) or FTP(s) transfer. In 7.18.2 the alias response_code was added to show the same info.)
http_connect The numerical code that was found in the last response (from a proxy) to a curl CONNECT request. (Added in 7.12.4)
time_total 总时间，按秒计。精确到小数点后三位。 （The total time, in seconds, that the full operation lasted. The time will be displayed with millisecond resolution.）
time_namelookup DNS解析时间,从请求开始到DNS解析完毕所用时间。(The time, in seconds, it took from the start until the name resolving was completed.)
time_connect 连接时间,从开始到建立TCP连接完成所用时间,包括前边DNS解析时间，如果需要单纯的得到连接时间，用这个time_connect时间减去前边time_namelookup时间。以下同理，不再赘述。(The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed.)
time_appconnect 连接建立完成时间，如SSL/SSH等建立连接或者完成三次握手时间。(The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed. (Added in 7.19.0))
time_pretransfer 从开始到准备传输的时间。(The time, in seconds, it took from the start until the file transfer was just about to begin. This includes all pre-transfer commands and negotiations that are specific to the particular protocol(s) involved.)
time_redirect 重定向时间，包括到最后一次传输前的几次重定向的DNS解析，连接，预传输，传输时间。(The time, in seconds, it took for all redirection steps include name lookup, connect, pretransfer and transfer before the final transaction was started. time_redirect shows the complete execution time for multiple redirections. (Added in 7.12.3))
time_starttransfer 开始传输时间。在client发出请求之后，Web 服务器返回数据的第一个字节所用的时间(The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result.)
size_download 下载大小。(The total amount of bytes that were downloaded.)
size_upload 上传大小。(The total amount of bytes that were uploaded.)
size_header 下载的header的大小(The total amount of bytes of the downloaded headers.)
size_request 请求的大小。(The total amount of bytes that were sent in the HTTP request.)
speed_download 下载速度，单位-字节每秒。(The average download speed that curl measured for the complete download. Bytes per second.)
speed_upload 上传速度,单位-字节每秒。(The average upload speed that curl measured for the complete upload. Bytes per second.)
content_type 就是content-Type，不用多说了，这是一个访问我博客首页返回的结果示例(text/html; charset=UTF-8)；(The Content-Type of the requested document, if there was any.)
num_connects Number of new connects made in the recent transfer. (Added in 7.12.3)
num_redirects Number of redirects that were followed in the request. (Added in 7.12.3)
redirect_url When a HTTP request was made without -L to follow redirects, this variable will show the actual URL a redirect would take you to. (Added in 7.18.2)
ftp_entry_path The initial path libcurl ended up in when logging on to the remote FTP server. (Added in 7.15.4)
ssl_verify_result ssl认证结果，返回0表示认证成功。( The result of the SSL peer certificate verification that was requested. 0 means the verification was successful. (Added in 7.19.0))
(1) application-limited ：when the sender sends less than is allowed by the congestion or receiver window.
(2) network-limited：when the sender is limited by the TCP window. More precisely, we define a network-limited period as any period when the sender is sending a full window of data.
问题1描述
TCP’s congestion window controls the number of packets a TCP flow may have in the
network at any time. However, long periods when the sender is idle or application-limited
can lead to the invalidation of the congestion window, in that the congestion window no longer
reflects current information about the state of the network.
The congestion window is set using an Additive-Increase, Multiplicative-Decrease(AIMD) mechanism
that probes for available bandwidth, dynamically adapting to changing network conditions. This AIMD
works well when the sender continually has data to send, as is typically the case for TCP used for
bulk-data transfer. In contrast, for TCP used with telnet applications, the data sender often has little
or no data to send, and the sending rate is often determined by the rate at which data is generated
by the user.
问题2描述
An invalid congestion window also results when the congestion window is increased (i.e.,
in TCP’s slow-start or congestion avoidance phases) during application-limited periods, when the
previous value of the congestion window might never have been fully utilized. As far as we know, all
current TCP implementations increase the congestion window when an acknowledgement arrives,
if allowed by the receiver’s advertised window and the slow-start or congestion avoidance window
increase algorithm, without checking to see if the previous value of the congestion window has in
fact been used.
This document proposes that the window increase algorithm not be invoked during application-
limited periods. This restriction prevents the congestion window from growing arbitrarily large,
in the absence of evidence that the congestion window can be supported by the network.
/* Congestion state accounting after a packet has been sent. */
static void tcp_event_data_sent (struct tcp_sock *tp, struct sock *sk)
{
struct inet_connection_sock *icsk = inet_csk(sk);
const u32 now = tcp_time_stamp;
if (sysctl_tcp_slow_start_after_idle &&
(!tp->packets_out && (s32) (now - tp->lsndtime) > icsk->icsk_rto))
tcp_cwnd_restart(sk, __sk_dst_get(sk)); /* 重置cnwd */
tp->lsndtime = now; /* 更新最近发包的时间*/
/* If it is a reply for ato after last received packets,
* enter pingpong mode. */
if ((u32)(now - icsk->icsk_ack.lrcvtime) < icsk.icsk_ack.ato)
icsk->icsk_ack.pingpong = 1;
}