document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-02-22 00:40:10 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'LCTT/master'

Browse Source
This commit is contained in:
Xingyu Wang 2020-08-12 11:49:42 +08:00
commit 4d19ccd366
7 changed files with 569 additions and 127 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
translated/tech/20200728 Digging for DNS answers on Linux.md → published/20200728 Digging for DNS answers on Linux.md
View File

@ -1,8 +1,8 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: (wxy)
[#]: publisher: ( )
[#]: url: ( )
[#]: publisher: (wxy)
[#]: url: (https://linux.cn/article-12509-1.html)
[#]: subject: (Digging for DNS answers on Linux)
[#]: via: (https://www.networkworld.com/article/3568488/digging-for-dns-answers-on-linux.html)
[#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/)
@ -12,7 +12,7 @@
> dig 是一个强大而灵活的工具，用于查询域名系统（DNS）服务器。在这篇文章中，我们将深入了解它的工作原理以及它能告诉你什么。
![Laurie Avocado][1]
![](https://img.linux.net.cn/data/attachment/album/202008/11/235200wlyytlaymlylfdff.jpg)
`dig` 是一款强大而灵活的查询 DNS 名称服务器的工具。它执行 DNS 查询，并显示参与该过程的名称服务器返回的应答以及与搜索相关的细节。系统管理员和 [DNS][3] 管理员经常使用 `dig` 来帮助排除 DNS 问题。在这篇文章中，我们将深入了解它的工作原理，看看它能告诉我们什么。
@ -53,7 +53,7 @@ idg.map.fastly.net. 30 IN A 151.101.250.165
- `SERVFAIL`：被查询的名称存在，但没有数据或现有数据无效。
- `NXDOMAIN`：所查询的名称不存在。
- `REFUSED`：该区域的数据不存在于所请求的权威服务器中，并且在这种情况下，基础设施没有设置为提供响应。
- `REFUSED`：该区域的数据不存在于所请求的权威服务器中，并且在这种情况下，基础设施没有设置为提供响应服务。
下面是一个例子，如果你要查找一个不存在的域名，你会看到什么？
@ -69,6 +69,8 @@ $ dig cannotbe.org
一般来说，`dig` 比 `ping` 会提供更多的细节，如果域名不存在，`ping` 会回复 “名称或服务未知”。当你查询一个合法的系统时，你可以看到域名系统对该系统知道些什么，这些记录是如何配置的，以及检索这些数据需要多长时间。
（LCTT 译注：`dig` 也比 `nslookup` 提供的数据更多。此外，`dig` 采用的是操作系统的解析库，而 `nslookup` 采用的是自己提供的解析库，这有时候会带来不同的行为。最后，有趣的一点是，`dig` 的返回的格式是符合 BIND 区域文件格式的。）
事实上，有时 `dig` 可以在 `ping` 完全不能响应的时候进行响应，当你试图确定一个连接问题时，这种信息是非常有用的。
### DNS 记录类型和标志

2
sources/talk/20160921 lawyer The MIT License, Line by Line.md
View File

@ -1,5 +1,5 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: translator: (hongcha8385)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )

121
sources/tech/20200807 install Fedora on a Raspberry Pi 3.md
View File

@ -1,121 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (install Fedora on a Raspberry Pi 3)
[#]: via: (https://fedoramagazine.org/install-fedora-on-a-raspberry-pi/)
[#]: author: (Nick Hardiman https://fedoramagazine.org/author/nickhardiman/)
install Fedora on a Raspberry Pi 3
======
![][1]
Fire up a Raspberry Pi with Fedora.
The [Raspberry Pi Foundation][2] has produced quite a few models over the years. This procedure was tested on third generation Pis – a [Model B v1.2][3], and a [Model B+][4] (the older [2][5] and the new [4][6] weren’t tested). These are the credit-card size Pis that have been around a few years.
### get hardware
You do need a few hardware items, including the Pi. You don’t need any [HaT (Hardware Attached on Top)][7] boards or USB antennas. If you have used your Pi in the past, you probably have all these items.
* **current network**. Perhaps this is your home lab.
* **ethernet cable**. This connects the current network to the Raspberry Pi
* **Raspberry Pi 3**, model B or B+.
* **power supply**
* **micro-SD card**, 8GB or larger.
* **keyboard** and **video monitor**.
The keyboard and video monitor together make up the local console. It’s possible – though complicated – to get by without a console, such as setting up an automated install then connecting over the network. A local console makes it easy to answer the configuration questions during Fedora’s first boot. Also, a mistake during AP configuration may break the network, locking out remote users.
### download Fedora Minimal
* Find Fedora’s [alternate architecture images][8].
* Download the [ARM® aarch64 Architecture image][9].
The _Fedora Minimal_ image, one of [Fedora’s alt downloads][10], has all the core packages and network packages required (well, nearly – check out _dnsmasq_ below). The image contains a ready-made file system, with over 400 packages already installed. This minimal image does not include popular packages like a development environment, Internet service or desktop. These types of software aren’t required for this work, and may well use too much memory if you install them.
The _Fedora Minimal_ raw image fits on a small SD card and runs in less than 1 GB of memory (these old Pis have 1GB RAM).
The name of the downloaded file is something like _Fedora-Minimal-32-1.6.aarch64.raw.xz_. The file is compressed and is about 700MB in size. When the file is uncompressed, it’s 5GB. It’s an ext4 file system that’s mostly empty – about 1GB is used and 4GB is empty. All that empty space is the reason the compressed download is so much smaller than the uncompressed raw image.
### copy to the micro-SD card
* Copy the image to a micro-SD card.
This can be a more complex than it sounds, and a painful experience. Finding a [good micro-SD card][11] takes work. Then there’s the challenge of physically attaching the card to your computer.Perhaps your laptop has a full SD card slot and you need a card adapter, or perhaps you need a USB adapter. Then, when it comes to copying, the OS may either help or get in your way. You may have luck with [Fedora Media Writer][12], or with these Linux commands.
```
unxz ./Fedora-Minimal-32-1.6.aarch64.raw.xz
dd if=./Fedora-Minimal-32-1.6.aarch64.raw of=/dev/mmcblk0 bs=8M status=progress oflag=direct
```
### set up Fedora
* Connect the Pi, power cable, network cable and micro-SD card.
* Hit the power.
* See the colored box as the graphics chip powers up.
* Wait for the [anaconda installer][13] to start.
* Answer anaconda’s setup questions.
Initial configuration of the OS takes a few minutes – a couple minutes waiting for boot-up, and a couple to fill out the spokes of anaconda’s text-based installer. In the examples below, the user is named **nick** and is an administrator (a member of the _wheel_ group).
Congratulations! Your Fedora Pi is up and operational.
### update software
* Update packages with `dnf update`.
* Reboot the machine with `systemctl reboot`.
Over the years, a lot of people have put a lot of work into making the Raspberry Pi devices work. Use the latest software to make sure you get the benefit of their hard work. If you skip this step, you may find some things just don’t work.
The update downloads and installs about a hundred packages. Since the storage is a micro-SD card, writing new software is a slow process. This is what using computing storage felt like in the 1990s.
### things to play with
There are a few other things that can be set up at this point, if you want to play around. It’s all optional. Try things like this.
* Replace the _localhost_ hostname with the command `sudo hostnamectl set-hostname raspi`.
* Find the IP address with `ip addr`.
* Try an SSH login, or even set up key-based login with `ssh-copy-id`.
* Power down with `systemctl poweroff`.
--------------------------------------------------------------------------------
via: https://fedoramagazine.org/install-fedora-on-a-raspberry-pi/
作者：[Nick Hardiman][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://fedoramagazine.org/author/nickhardiman/
[b]: https://github.com/lujun9972
[1]: https://fedoramagazine.org/wp-content/uploads/2020/07/fedora-on-rpi-816x346.png
[2]: https://www.raspberrypi.org/about/
[3]: https://www.raspberrypi.org/products/raspberry-pi-3-model-b/
[4]: https://www.raspberrypi.org/products/raspberry-pi-3-model-b-plus/
[5]: https://www.raspberrypi.org/products/raspberry-pi-2-model-b/
[6]: https://www.raspberrypi.org/products/raspberry-pi-4-model-b/
[7]: https://www.raspberrypi.org/blog/introducing-raspberry-pi-hats/
[8]: https://alt.fedoraproject.org/alt/
[9]: https://download.fedoraproject.org/pub/fedora-secondary/releases/32/Spins/aarch64/images/Fedora-Minimal-32-1.6.aarch64.raw.xz
[10]: https://alt.fedoraproject.org/
[11]: https://www.jeffgeerling.com/blog/2019/raspberry-pi-microsd-card-performance-comparison-2019
[12]: https://fedoramagazine.org/make-fedora-usb-stick/
[13]: https://fedoraproject.org/wiki/Anaconda

103
sources/tech/20200811 Don-t ignore .gitignore.md Normal file
View File

@ -0,0 +1,103 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Don't ignore .gitignore)
[#]: via: (https://opensource.com/article/20/8/dont-ignore-gitignore)
[#]: author: (Rajeev Bera https://opensource.com/users/acompiler)
Don't ignore .gitignore
======
Using a .gitignore file is a best practice for improving the quality of
your code and Git repositories.
![Business woman on laptop sitting in front of window][1]
I have noticed that many developers do not use a .gitignore file, even though it's a [best practice][2] to use one to designate files you don't want Git to track in version control. Because .gitignore can boost your code quality, you should not ignore [.gitignore][3] in your repositories.
### What is .gitignore?
Files in your working Git repository can be:
1. **Untracked:** Changes that have not been staged or committed
2. **Tracked:** Changes that have been staged or committed
3. **Ignored:** Files you tell Git to ignore
There are some files you want Git to ignore and not track in your repository. These include many that are auto-generated or platform-specific, as well as other local configuration files such as:
1. Files with sensitive information
2. Compiled code, such as `.dll` or `.class`
3. System files like `.DS_Store` or `Thumbs.db`
4. Files with temporary information such as logs, caches, etc.
5. Generated files such as `dist` folders
If you don't want Git to track certain files in your repository, there is no [Git command][4] you can use. (Although you can stop tracking a file with the `git rm` command, such as `git rm --cached`.) Instead, you need to use a .gitignore file, a text file that tells Git which files not to track.
It's easy to create a .gitignore file; just create a text file and name it .gitignore. Remember to add a single dot (`.`) at the beginning of the file name. That's it!
### Rules for writing a .gitignore file
According to the [documentation][3], "each line in a .gitignore file specifies a pattern."
In this context, a "pattern" can refer to a specific filename, or to some part of a filename combined with a wildcard character. In other words, **example.txt** is a valid pattern that matches a file called **example.txt**, while **ex*txt** is a valid pattern that matches a file called **example.txt** as well as a file called **export.txt**.
Here are some basic rules to help you to set up your .gitignore file correctly:
1. Any line that starts with a hash (`#`) is a comment.
2. The `\` character escapes special characters.
3. The `/` character means that the rule applies only to files and folders located in the same folder.
4. An asterisk (`*`) means any number of characters (zero or more).
5. Two asterisks (`**`) specify any number of subdirectories.
6. A question mark (`?`) replaces zero or one character.
7. An exclamation sign (`!`) designates the inversion rule (i.e., it includes any file that was excluded by a previous pattern).
8. Blank lines are ignored, so you can use them to add space and make your file easier to read.
9. Adding `/` on the end ignores entire directory paths.
### Local vs. global .gitignore files
There are two types of .gitignore files:
* **Local:** Placed in the root of your Git repository, works only on that repository, and must be committed to the repository
* **Global:** Placed in the root of your home directory, affects every repository you use on your machine, does not need to be committed
Many developers use a local .gitignore file in their project repository, but very few use the global .gitignore file. The most significant advantages of using a global file are that you don't need to commit it to use it and making one change affects all your repositories.
### Advantages of Git ignore
There are other advantages to using a .gitignore file beyond ensuring specific files are not tracked by Git:
1. It helps you keep your code repository clean by ignoring unwanted files.
2. It keeps your repository size under control, which is especially helpful if you are working on a big project.
3. Every commit, push, and pull request you make will be clean.
### Conclusion
Git is powerful, but in the end, it's just another computer program. It's a team effort to use best practices and keep your code repo stable, and part of this is using a .gitignore file.
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/8/dont-ignore-gitignore
作者：[Rajeev Bera][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/acompiler
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/lenovo-thinkpad-laptop-concentration-focus-windows-office.png?itok=-8E2ihcF (Woman using laptop concentrating)
[2]: https://opensource.com/article/20/7/git-repos-best-practices
[3]: https://git-scm.com/docs/gitignore
[4]: https://acompiler.com/git-commands/

2
sources/tech/20200811 Photoflare- An Open Source Image Editor for Simple Editing Needs.md
View File

@ -1,5 +1,5 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )

337
sources/tech/20200811 TCP window scaling, timestamps and SACK.md Normal file
View File

@ -0,0 +1,337 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (TCP window scaling, timestamps and SACK)
[#]: via: (https://fedoramagazine.org/tcp-window-scaling-timestamps-and-sack/)
[#]: author: (Florian Westphal https://fedoramagazine.org/author/strlen/)
TCP window scaling, timestamps and SACK
======
![][1]
The Linux TCP stack has a myriad of _sysctl_ knobs that allow to change its behavior.  This includes the amount of memory that can be used for receive or transmit operations, the maximum number of sockets and optional features and protocol extensions.
There are  multiple articles that recommend to disable TCP extensions, such as timestamps or selective acknowledgments (SACK) for various “performance tuning” or “security” reasons.
This article provides background on what these extensions do, why they
are enabled by default, how they relate to one another and why it is normally a bad idea to turn them off.
### TCP Window scaling
The data transmission rate that TCP can sustain is limited by several factors. Some of these are:
* Round trip time (RTT).  This is the time it takes for a packet to get to the destination and a reply to come back. Lower is better.
* lowest link speed of the network paths involved
* frequency of packet loss
* the speed at which new data can be made available for transmission
For example, the CPU needs to be able to pass data to the network adapter fast enough. If the CPU needs to encrypt the data first, the adapter might have to wait for new data. In similar fashion disk storage can be a bottleneck if it can’t read the data fast enough.
* The maximum possible size of the TCP receive window. The receive window determines how much data (in bytes) TCP can transmit before it has to wait for the receiver to report reception of that data. This is announced by the receiver. The receiver will constantly update this value as it reads and acknowledges reception of the incoming data. The receive windows current value is contained in the [TCP header][2] that is part of every segment sent by TCP. The sender is thus aware of the current receive window whenever it receives an acknowledgment from the peer. This means that the higher the round-trip time, the longer it takes for sender to get receive window updates.
TCP is limited to at most 64 kilobytes of unacknowledged (in-flight) data. This is not even close to what is needed to sustain a decent data rate in most networking scenarios. Let us look at some examples.
##### Theoretical data rate
With a round-trip-time of 100 milliseconds, TCP can transfer at most 640 kilobytes per second. With a 1 second delay, the maximum theoretical data rate drops down to only 64 kilobytes per second.
This is because of the receive window. Once 64kbyte of data have been sent the receive window is already full.  The sender must wait until the peer informs it that at least some of the data has been read by the application. 
The first segment sent reduces the TCP window by the size of that segment. It takes one round-trip before an update of the receive window value will become available. When updates arrive with a 1 second delay, this results in a 64 kilobyte limit even if the link has plenty of bandwidth available.
In order to fully utilize a fast network with several milliseconds of delay, a window size larger than what classic TCP supports is a must. The ’64 kilobyte limit’ is an artifact of the protocols specification: The TCP header reserves only 16bits for the receive window size. This allows receive windows of up to 64KByte. When the TCP protocol was originally designed, this size was not seen as a limit.
Unfortunately, its not possible to just change the TCP header to support a larger maximum window value. Doing so would mean all implementations of TCP would have to be updated simultaneously or they wouldn’t understand one another anymore. To solve this, the interpretation of the receive window value is changed instead.
The ‘window scaling option’ allows to do this while keeping compatibility to existing implementations.
#### TCP Options: Backwards-compatible protocol extensions
TCP supports optional extensions. This allows to enhance the protocol with new features without the need to update all implementations at once. When a TCP initiator connects to the peer, it also send a list of supported extensions. All extensions follow the same format: an unique option number followed by the length of the option and the option data itself.
The TCP responder checks all the option numbers contained in the connection request. If it does not understand an option number it skips
‘length’ bytes of data and checks the next option number. The responder omits those it did not understand from the reply. This allows both the sender and receiver to learn the common set of supported options.
With window scaling, the option data always consist of a single number.
### The window scaling option
```
```
Window Scale option (WSopt): Kind: 3, Length: 3
    +---------+---------+---------+
    | Kind=3  |Length=3 |shift.cnt|
    +---------+---------+---------+
         1         1         1
```
```
The [window scaling][3] option tells the peer that the receive window value found in the TCP header should be scaled by the given number to get the real size.
For example, a TCP initiator that announces a window scaling factor of 7 tries to instruct the responder that any future packets that carry a receive window value of 512 really announce a window of 65536 byte. This is an increase by a factor of 128. This would allow a maximum TCP Window of 8 Megabytes.
A TCP responder that does not understand this option ignores it. The TCP packet sent in reply to the connection request (the syn-ack) then does not contain the window scale option. In this case both sides can only use a 64k window size. Fortunately, almost every TCP stack supports and enables this option by default, including Linux.
The responder includes its own desired scaling factor. Both peers can use a different number. Its also legitimate to announce a scaling factor of 0. This means the peer should treat the receive window value it receives verbatim, but it allows scaled values in the reply direction — the recipient can then use a larger receive window.
Unlike SACK or TCP timestamps, the window scaling option only appears in the first two packets of a TCP connection, it cannot be changed afterwards. It is also not possible to determine the scaling factor by looking at a packet capture of a connection that does not contain the initial connection three-way handshake.
The largest supported scaling factor is 14. This allows TCP window sizes
of up to one Gigabyte.
##### Window scaling downsides
It can cause data corruption in very special cases. Before you disable the option – it is impossible under normal circumstances. There is also a solution in place that prevents this. Unfortunately, some people disable this solution without realizing the relationship with window scaling. First, let’s have a look at the actual problem that needs to be addressed. Imagine the following sequence of events:
1. The sender transmits segments: s_1, s_2, s_3, … s_n
2.  The receiver sees: s_1, s_3, .. s_n and sends an acknowledgment for s_1.
3.  The sender considers s_2 lost and sends it a second time. It also sends new data contained in segment s_n+1.
4.  The receiver then sees: s_2, s_n+1, s_2: the packet s_2 is received twice.
This can happen for example when a sender triggers re-transmission too early. Such erroneous re-transmits are never a problem in normal cases, even with window scaling. The receiver will just discard the duplicate.
#### Old data to new data
The TCP sequence number can be at most 4 Gigabyte. If it becomes larger than this, the sequence wraps back to 0 and then increases again. This is not a problem in itself, but if this occur fast enough then the above scenario can create an ambiguity.
If a wrap-around occurs at the right moment, the sequence number s_2 (the re-transmitted packet) can already be larger than s_n+1. Thus, in the last step (4), the receiver may interpret this as: s_2, s_n+1, s_n+m, i.e. it could view the ‘old’ packet s_2 as containing new data.
Normally, this won’t happen because a ‘wrap around’ occurs only every couple of seconds or minutes even on high bandwidth links. The interval between the original and a unneeded re-transmit will be a lot smaller.
For example,with a transmit speed of 50 Megabytes per second, a
duplicate needs to arrive more than one minute late for this to become a problem. The sequence numbers do not wrap fast enough for small delays to induce this problem.
Once TCP approaches ‘Gigabyte per second’ throughput rates, the sequence numbers can wrap so fast that even a delay by only a few milliseconds can create duplicates that TCP cannot detect anymore. By solving the problem of the too small receive window, TCP can now be used for network speeds that were impossible before – and that creates a new, albeit rare problem. To safely use Gigabytes/s speed in environments with very low RTT receivers must be able to detect such old duplicates without relying on the sequence number alone.
### TCP time stamps
#### A best-before date
In the most simple terms, [TCP timestamps][3] just add a time stamp to the packets to resolve the ambiguity caused by very fast sequence number wrap around. If a segment appears to contain new data, but its timestamp is older than the last in-window packet, then the sequence number has wrapped and the ”new” packet is actually an older duplicate. This resolves the ambiguity of re-transmits even for extreme corner cases.
But this extension allows for more than just detection of old packets. The other major feature made possible by TCP timestamps are more precise round-trip time measurements (RTTm).
#### A need for precise round-trip-time estimation
When both peers support timestamps,  every TCP segment carries two additional numbers: a timestamp value and a timestamp echo.
```
```
TCP Timestamp option (TSopt): Kind: 8, Length: 10
+-------+----+----------------+-----------------+
|Kind=8 | 10 |TS Value (TSval)|EchoReply (TSecr)|
+-------+----+----------------+-----------------+
    1      1         4                4
```
```
An accurate RTT estimate is crucial for TCP performance. TCP automatically re-sends data that was not acknowledged. Re-transmission is triggered by a timer: If it expires, TCP considers one or more packets that it has not yet received an acknowledgment for to be lost. They are then sent again.
But “has not been acknowledged” does not mean the segment was lost. It is also possible that the receiver did not send an acknowledgment so far or that the acknowledgment is still in flight. This creates a dilemma: TCP must wait long enough for such slight delays to not matter, but it can’t wait for too long either.
##### Low versus high network delay
In networks with a high delay, if the timer fires too fast, TCP frequently wastes time and bandwidth with unneeded re-sends.
In networks with a low delay however,  waiting for too long causes reduced throughput when a real packet loss occurs. Therefore, the timer should expire sooner in low-delay networks than in those with a high delay. The tcp retransmit timeout therefore cannot use a fixed constant value as a timeout. It needs to adapt the value based on the delay that it experiences in the network.
##### Round-trip time measurement
TCP picks a retransmit timeout that is based on the expected round-trip time (RTT). The RTT is not known in advance. RTT is estimated by measuring the delta between the time a segment is sent and the time TCP receives an acknowledgment for the data carried by that segment.
This is complicated by several factors.
* For performance reasons, TCP does not generate a new acknowledgment for every packet it receives. It waits  for a very small amount of time: If more segments arrive, their reception can be acknowledged with a single ACK packet. This is called “cumulative ACK”.
*  The round-trip-time is not constant. This is because of a myriad of factors. For example, a client might be a mobile phone switching to different base stations as its moved around. Its also possible that packet switching takes longer when link or CPU utilization increases.
* a packet that had to be re-sent must be ignored during computation. This is because the sender cannot tell if the ACK for the re-transmitted segment is acknowledging the original transmission (that arrived after all) or the re-transmission.
This last point is significant: When TCP is busy recovering from a loss, it may only receives ACKs for re-transmitted segments. It then can’t measure (update) the RTT during this recovery phase. As a consequence it can’t adjust the re-transmission timeout, which then keeps growing exponentially. That’s a pretty specific case (it assumes that other mechanisms such as fast retransmit or SACK did not help). Nevertheless, with TCP timestamps, RTT evaluation is done even in this case.
If the extension is used, the peer reads the timestamp value from the TCP segments extension space and stores it locally. It then places this value in all the segments it sends back as the “timestamp echo”.
Therefore the option carries two timestamps: Its senders own timestamp and the most recent timestamp it received from the peer. The “echo timestamp” is used by the original sender to compute the RTT. Its the delta between its current timestamp clock and what was reflected in the “timestamp echo”.
##### Other timestamp uses
TCP timestamps even have other uses beyond PAWS and RTT measurements. For example it becomes possible to detect if a retransmission was unnecessary. If the acknowledgment carries an older timestamp echo, the acknowledgment was for the initial packet, not the re-transmitted one.
Another, more obscure use case for TCP timestamps is related to the TCP [syn cookie][4] feature.
##### TCP connection establishment on server side
When connection requests arrive faster than a server application can accept the new incoming connection, the connection backlog will eventually reach its limit. This can occur because of a mis-configuration of the system or a bug in the application. It also happens when one or more clients send connection requests without reacting to the ‘syn ack’ response. This fills the connection queue with incomplete connections. It takes several seconds for these entries to time out. This is called a “syn flood attack”.
##### TCP timestamps and TCP syn cookies
Some TCP stacks allow to accept new connections even if the queue is full. When this happens, the Linux kernel will print a prominent message to the system log:
> Possible SYN flooding on port P. Sending Cookies. Check SNMP counters.
This mechanism bypasses the connection queue entirely. The information that is normally stored in the connection queue is encoded into the SYN/ACK responses TCP sequence number. When the ACK comes back, the queue entry can be rebuilt from the sequence number.
The sequence number only has limited space to store information. Connections established using the ‘TCP syn cookie’ mechanism can not support TCP options for this reason.
The TCP options that are common to both peers can be stored in the timestamp, however. The ACK packet reflects the value back in the timestamp echo field which allows to recover the agreed-upon TCP options as well. Else, cookie-connections are restricted by the standard 64 kbyte receive window.
##### Common myths – timestamps are bad for performance
Unfortunately some guides recommend disabling TCP timestamps to reduce the number of times the kernel needs to access the timestamp clock to get the current time. This is not correct. As explained before, RTT estimation is a necessary part of TCP. For this reason, the kernel always takes a microsecond-resolution time stamp when a packet is received/sent.
Linux re-uses the clock timestamp taken for the RTT estimation for the remainder of the packet processing step. This also avoids the extra clock access to add a timestamp to an outgoing TCP packet.
The entire timestamp option only requires 10 bytes of TCP option space in each packet, this is not a significant decrease in space available for packet payload.
##### common myths – timestamps are a security problem
Some security audit tools and (older) blog posts recommend to disable TCP
timestamps because they allegedly leak system uptime: This would then allow to estimate the patch level of the system/kernel. This was true in the past: The timestamp clock is based on a constantly increasing value that starts at a fixed value on each system boot. A timestamp value would give a estimate as to how long the machine has been running (uptime).
As of Linux 4.12 TCP timestamps do not reveal the uptime anymore. All timestamp values sent use a peer-specific offset. Timestamp values also wrap every 49 days.
In other words, connections from or to address “A” see a different timestamp than connections to the remote address “B”.
Run _sysctl net.ipv4.tcp_timestamps=2_ to disable the randomization offset. This makes analyzing packet traces recorded by tools like _wireshark_ or _tcpdump_ easier – packets sent from the host then all have the same clock base in their TCP option timestamp.  For normal operation the default setting should be left as-is.
### Selective Acknowledgments
TCP has problems if several packets in the same window of data are lost. This is because TCP Acknowledgments are cumulative, but only for packets
that arrived in-sequence. Example:
* Sender transmits segments s_1, s_2, s_3, … s_n
* Sender receives ACK for s_2
* This means that both s_1 and s_2 were received and the
sender no longer needs to keep these segments around.
* Should s_3 be re-transmitted? What about s_4? s_n?
The sender waits for a “retransmission timeout” or ‘duplicate ACKs’ for s_2 to arrive. If a retransmit timeout occurs or several duplicate ACKs for s_2 arrive, the sender transmits s_3 again.
If the sender receives an acknowledgment for s_n, s_3 was the only missing packet. This is the ideal case. Only the single lost packet was re-sent.
If the sender receives an acknowledged segment that is smaller than s_n, for example s_4, that means that more than one packet was lost. The
sender needs to re-transmit the next segment as well.
##### Re-transmit strategies
Its possible to just repeat the same sequence: re-send the next packet until the receiver indicates it has processed all packet up to s_n. The problem with this approach is that it requires one RTT until the sender knows which packet it has to re-send next. While such strategy avoids unnecessary re-transmissions, it can take several seconds and more until TCP has re-sent the entire window of data.
The alternative is to re-send several packets at once. This approach allows TCP to recover more quickly when several packets have been lost. In the above example TCP re-send s_3, s_4, s_5, .. while it can only be sure that s_3 has been lost.
From a latency point of view, neither strategy is optimal. The first strategy is fast if only a single packet has to be re-sent, but takes too long when multiple packets were lost.
The second one is fast even if multiple packet have to be re-sent, but at the cost of wasting bandwidth. In addition, such a TCP sender could have transmitted new data already while it was doing the unneeded re-transmissions.
With the available information TCP cannot know which packets were lost. This is where TCP [Selective Acknowledgments][5] (SACK) come in. Just like window scaling and timestamps, it is another optional, yet very useful TCP feature.
##### The SACK option
```
```
   TCP Sack-Permitted Option: Kind: 4, Length 2
   +---------+---------+
   | Kind=4  | Length=2|
   +---------+---------+
```
```
A sender that supports this extension includes the “Sack Permitted” option in the connection request. If both endpoints support the extension, then a peer that detects a packet is missing in the data stream can inform the sender about this.
```
```
   TCP SACK Option: Kind: 5, Length: Variable
                     +--------+--------+
                     | Kind=5 | Length |
   +--------+--------+--------+--------+
   |      Left Edge of 1st Block       |
   +--------+--------+--------+--------+
   |      Right Edge of 1st Block      |
   +--------+--------+--------+--------+
   |                                   |
   /            . . .                  /
   |                                   |
   +--------+--------+--------+--------+
   |      Left Edge of nth Block       |
   +--------+--------+--------+--------+
   |      Right Edge of nth Block      |
   +--------+--------+--------+--------+
```
```
A receiver that encounters segment_s2 followed by s_5…s_n, it will include a SACK block when it sends the acknowledgment for s_2:
```
```
                +--------+-------+
                | Kind=5 |   10  |
+--------+------+--------+-------+
| Left edge: s_5                 |
+--------+--------+-------+------+
| Right edge: s_n                |
+--------+-------+-------+-------+
```
```
This tells the sender that segments up to s_2 arrived in-sequence, but it also lets the sender know that the segments s_5 to s_n were also received. The sender can then re-transmit these two packets and proceed to send new data.
##### The mythical lossless network
In theory SACK provides no advantage if the connection cannot experience packet loss. Or the connection has such a low latency that even waiting one full RTT does not matter.
In practice lossless behavior is virtually impossible to ensure.
Even if the network and all its switches and routers have ample bandwidth and buffer space packets can still be lost:
* The host operating system might be under memory pressure and drop
packets. Remember that a host might be handling tens of thousands of packet streams simultaneously.
* The CPU might not be able to drain incoming packets from the network interface fast enough. This causes packet drops in the network adapter itself.
* If TCP timestamps are not available even a connection with a very small RTT can stall momentarily during loss recovery.
Use of SACK does not increase the size of TCP packets unless a connection experiences packet loss. Because of this, there is hardly a reason to disable this feature. Almost all TCP stacks support SACK – it is typically only absent on low-power IOT-alike devices that are not doing TCP bulk data transfers.
When a Linux system accepts a connection from such a device, TCP automatically disables SACK for the affected connection.
### Summary
The three TCP extensions examined in this post are all related to TCP performance and should best be left to the default setting: enabled.
The TCP handshake ensures that only extensions that are understood by both parties are used, so there is never a need to disable an extension globally just because a peer might not support it.
Turning these extensions off results in severe performance penalties, especially in case of TCP Window Scaling and SACK. TCP timestamps can be disabled without an immediate disadvantage, however there is no compelling reason to do so anymore. Keeping them enabled also makes it possible to support TCP options even when SYN cookies come into effect.
--------------------------------------------------------------------------------
via: https://fedoramagazine.org/tcp-window-scaling-timestamps-and-sack/
作者：[Florian Westphal][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://fedoramagazine.org/author/strlen/
[b]: https://github.com/lujun9972
[1]: https://fedoramagazine.org/wp-content/uploads/2020/08/tcp-window-scaling-816x346.png
[2]: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure
[3]: https://www.rfc-editor.org/info/rfc7323
[4]: https://en.wikipedia.org/wiki/SYN_cookies
[5]: https://www.rfc-editor.org/info/rfc2018

121
translated/tech/20200807 install Fedora on a Raspberry Pi 3.md Normal file
View File

@ -0,0 +1,121 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (install Fedora on a Raspberry Pi 3)
[#]: via: (https://fedoramagazine.org/install-fedora-on-a-raspberry-pi/)
[#]: author: (Nick Hardiman https://fedoramagazine.org/author/nickhardiman/)
在树莓派 3 上安装 Fedora
======
![][1]
在树莓派上运行 Fedora。
[树莓派基金会][2]这几年来已经生产了很多型号。过程已经在第三代树莓派上进行了测试：[Model B v1.2][3] 和 [Model B+][4]（较旧的 [2][5] 和新的 [4][6] 都还没有测试）。这些是已经发布几年的信用卡大小的树莓派。
### 获取硬件
你确实需要一些硬件，包括树莓派。你不需要任何 [HaT（安装在顶部的硬件）][7] 板或 USB 天线。如果你使用过树莓派，那么可能会有这些。
* **当前网络**。也许是你的家庭实验室。
* **网线**。连接当前网络到树莓派
* **树莓派 3**，model B 或 B+。
* **电源供应**。
* **8 GB 或更大容量的 micro-SD 卡**。
* **键盘**和**显示器**。
键盘和显示器共同组成本地控制台。即使没有控制台，也有可能（尽管很复杂）进行操作，例如设置自动安装然后通过网络连接。在 Fedora 首次启动时，本地控制台可轻松回应配置问题。同样，在 AP 配置期间出错可能会破坏网络，从而锁定远程用户。
### 下载 Fedora Minimal
* 查找 Fedora 的[其他可选架构镜像][8]。
* 下载 [ARM® aarch64 架构镜像][9]。
_Fedora Minimal_ 镜像是 [Fedora 的其他可选下载之一][10]，它有所有必需的核心软件包和网络软件包（嗯，是几乎，请查看下面的 _dnsmasq_）。该镜像包含一个现成的文件系统，它已经安装了 400 多个软件包。此最小镜像不包括流行的软件包，像开发环境、互联网服务或桌面。这些类型的软件不是这里所必需的，如果安装它们，可能会占用过多的内存。
_Fedora Minimal_ 原始镜像可安装在小型 SD 卡上，并在少于 1GB 的内存中运行（这些旧的树莓派有1GB 的内存）。
下载文件的名称类似于 _Fedora-Minimal-32-1.6.aarch64.raw.xz_。该文件已压缩，大小约为 700MB。文件解压缩后为 5GB。这是一个 ext4 文件系统，它几乎是空的：已使用约1GB，4GB 是空的。这些空的空间是压缩文件比未压缩的原始文件小得多的原因。
### 复制到 micro-SD 卡
*将镜像复制到 micro-SD 卡。
这可能比听起来更复杂，而且会带来痛苦的体验。找到[良好的 micro-SD 卡][11]即可。然后是将卡插到计算机的挑战。也许你的笔记本电脑有全尺寸的 SD 卡插槽，你还需要卡适配器，或者你需要一个 USB 适配器。然后，在进行复制时，操作系统可能会帮助你，也可能会妨碍你。你可能很幸运有 [Fedora Media Writer][12] 或这些 Linux 命令。
```
unxz ./Fedora-Minimal-32-1.6.aarch64.raw.xz
dd if=./Fedora-Minimal-32-1.6.aarch64.raw of=/dev/mmcblk0 bs=8M status=progress oflag=direct
```
### 安装 Fedora
* 连接树莓派、电源线、网线和 micro-SD 卡。
* 打开电源。
* 当图形芯片通电时，看见彩色框。
* 等待 [anaconda 安装程序][13]启动。
* 回应 anaconda 的设置问题。
操作系统的初始配置需要几分钟的时间。等待启动需要花费几分钟，还需要花费一些时间填写 anaconda 基于文本的安装程序的问题。在下面的例子中，用户名为 **nick**，并且还是管理员（_wheel_ 组的成员）。
恭喜你！你的树莓派已启动并可运行。
### 更新软件
* 用 `dnf update` 更新软件包。
* 通过 `systemctl reboot` 重启。
多年来，很多人为使树莓派正常工作付出了很多工作。使用最新的软件，以确保你从他们的辛勤工作中受益。如果你跳过此步骤，你可能会发现有些东西无法正常工作。
此次更新下载并安装了约一百个软件包。由于存储设备是 micro-SD 卡，因此写入新软件的过程很慢。这就是 90 年代使用存储器的感觉。
### 可以摆弄的东西
如果你想摆弄的话，此时可以设置其他一些内容。这都是可选的。试试这些。
* `sudo hostnamectl set-hostname raspi` 替换 _localhost_ 主机名。
* 用 `ip addr` 查找 IP 地址。
* 尝试 SSH 登录，甚至使用 `ssh-copy-id` 设置基于密钥的登录。
* 使用 `systemctl poweroff` 关机。
--------------------------------------------------------------------------------
via: https://fedoramagazine.org/install-fedora-on-a-raspberry-pi/
作者：[Nick Hardiman][a]
选题：[lujun9972][b]
译者：[geekpi](https://github.com/geekpi)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://fedoramagazine.org/author/nickhardiman/
[b]: https://github.com/lujun9972
[1]: https://fedoramagazine.org/wp-content/uploads/2020/07/fedora-on-rpi-816x346.png
[2]: https://www.raspberrypi.org/about/
[3]: https://www.raspberrypi.org/products/raspberry-pi-3-model-b/
[4]: https://www.raspberrypi.org/products/raspberry-pi-3-model-b-plus/
[5]: https://www.raspberrypi.org/products/raspberry-pi-2-model-b/
[6]: https://www.raspberrypi.org/products/raspberry-pi-4-model-b/
[7]: https://www.raspberrypi.org/blog/introducing-raspberry-pi-hats/
[8]: https://alt.fedoraproject.org/alt/
[9]: https://download.fedoraproject.org/pub/fedora-secondary/releases/32/Spins/aarch64/images/Fedora-Minimal-32-1.6.aarch64.raw.xz
[10]: https://alt.fedoraproject.org/
[11]: https://www.jeffgeerling.com/blog/2019/raspberry-pi-microsd-card-performance-comparison-2019
[12]: https://fedoramagazine.org/make-fedora-usb-stick/
[13]: https://fedoraproject.org/wiki/Anaconda