Какие параметры влияют на производительность приложений? Часть 1. TCP Window Size
Самый простой способ понять значение термина размер TCP окна (TCP Window Size), это представить разговор двух человек. Один человек говорит, а второй кивает головой или говорит да, тем самым подтверждая, что он понял, а по сути, получил все слова, которые ему были сказаны. После этого разговор продолжается. Если мы встречаем особо говорливого человека, то наша голова быстро загружается, и мы начинаем терять нить разговора или переспрашивать нашего собеседника. Тоже самое происходит и в Матрице — в мире цифр и машин.
Размер TCP окна (TCP Window Size) – количество октетов (начиная с номера подтверждения), которое принимающая сторона готова принять в настоящий момент без подтверждения. На стадии установления соединения рабочая станция и сервер обмениваются значениями максимального размера TCP окна (TCP Window Size), которые присутствуют в пакете и эти значения можно легко увидеть, воспользовавшись захватом трафика.
Например, если размер окна получателя равен 16384 байта, то отправитель может отправить 16384 байта без остановки. Принимая во внимание, что максимальная длина сегмента (MSS) может быть 1460 байт, то отправитель сможет передать данный объем в 12 фреймах, и затем будет ждать подтверждение доставки от получателя и информации по обновлению размера окна. Если процесс прошел без ошибок, то размер окна может быть увеличен. Таким образом, реализуется размер скользящего окна в стеке протокола TCP.
В зависимости от состояния каналов связи, размер окна может быть больше или меньше. Каналы связи могут быть высокоскоростными (большая пропускная способность) и протяженными (большая задержка и возможно потери), поэтому при небольшом размере TCP окна мы будем вынуждены отправлять один или несколько фреймов и ждать подтверждения от получателя, затем процесс повторяется. Таким образом, наши приложения будут неэффективно использовать доступную полосу пропускания. Пакетов будет много, но реального полезного трафика будет передано не много. Чтобы получить максимальную пропускную способность, необходимо использовать оптимально установленный размер передающего и принимающего окна для канала, который вы используете.
Для расчёта максимального размера окна (т.е. максимальный объем данных, которые могут передаваться одним пользователем другому в канале связи) рассчитывается по формуле:
Полоса пропускания (бит/сек) * RTT (круговое время передачи по сети) = размер окна в битах
Таким образом, если ваши два офиса соединяет канал связи в 10 Мбит/сек и круговое время составляет 85 миллисекунд, то воспользовавшись данной формулой, мы получим значение окна равное:
10 000 000 * 0,085 / 8 = 106250 байт
Размер поля Window в заголовке TCP составляет 16 бит; это означает, что узел TCP может указать максимальный размер TCP окна 65535 байт. Таким образом, максимальная пропускная способность составляет:
65535 * 8 / 0,085 = 6,2 Мбит/сек
т.е. чуть больше 50% от реально доступной полосы пропускания канала.
В современных версиях операционных систем можно увеличить размер окна TCP Window Size и включить динамическое изменение окна в зависимости от состояния канала связи. В предложении RFC 1323 дано определение масштабирования окон, позволяющего получателю указывать размер окна больше 65535 байт, что позволит применять большие размеры окон и высокоскоростные каналы передачи. Параметр TCP Window Scale указывает коэффициент масштабирования окна, который в сочетании с 16-битным полем Window в заголовке TCP может увеличивать размер окна приема до максимального значения, составляющего примерно 1 ГБ. Параметр Window Scale отправляется только в сегментах синхронизации (SYN) при установке соединения. На нашем скриншоте из WireShark он составляет 256. Устройства, общающиеся друг с другом, могут указывать разные коэффициенты масштабирования для TCP окон.
Таким образом, активировав масштабирование окон TCP и уменьшив круговое время передачи по сети, мы сможем повысить эффективность использования доступной полосы пропускания и как следствие скорость работы приложений. А проверить это можно захватив пакеты, и посмотреть о каких значениях размера окна и коэффициенте масштабирования договорились устройства в момент установки соединения. Это динамическое увеличение и уменьшение размера окна является непрерывным процессом в TCP и определяет оптимальный размер окна для каждого сеанса. В очень эффективных сетях размеры окна могут стать очень большими, потому что данные не теряются. В сетях, где сетевая инфраструктура перегружена, размер окна, вероятно, останется маленьким.
См. также:
- Какие параметры влияют на производительность приложений? Часть 2. Полоса пропускания и использование канала связи
- 5 недостатков Wireshark: в чём бесплатный сниффер проигрывает коммерческим аналогам?
- Какие функциональные возможности должны быть у решения для мониторинга производительности сети?
Когда мы говорим о скорости соединения, важное понятие, о котором стоит упомянуть, — это TCP windows size, или размер окна TCP. Это параметр, который определяет, сколько данных может быть отправлено или принято в рамках одного TCP-сегмента без подтверждения.
Размер окна TCP влияет на эффективность передачи данных и скорость соединения. Если окно TCP слишком маленькое, то операция передачи данных может быть замедлена из-за постоянных подтверждений получения данных. Если окно TCP слишком большое, то возможна потеря данных и восстановление соединения может занять больше времени.
Оптимальное значение размера окна TCP зависит от различных факторов, таких как пропускная способность сети, задержка сети и пропускная способность принимающего устройства. Для достижения максимальной скорости соединения необходимо настроить размер окна TCP таким образом, чтобы он был оптимальным для конкретных условий сети.
Исправность настройки размера окна TCP может значительно увеличить скорость соединения и повысить производительность сети в целом.
Теперь, когда мы знаем, что такое TCP windows size и как оно влияет на скорость соединения, становится очевидно, что правильная настройка этого параметра является важным шагом в оптимизации сети и обеспечении эффективной передачи данных.
Содержание
- Что такое TCP windows size?
- Как работает TCP windows size?
- Зачем нужно управление TCP window size?
- Как влияет TCP windows size на скорость соединения?
Что такое TCP windows size?
Когда отправитель передает данные в сегменте TCP, он помещает эти данные в окно. Получатель пересылает подтверждение, указывая отправителю, какое количество данных он получил успешно. Размер окна может изменяться в процессе соединения в зависимости от различных факторов.
Размер окна TCP имеет прямое влияние на скорость соединения. Больший размер окна позволяет отправителю передавать больше данных перед ожиданием подтверждения. Это позволяет использовать полную пропускную способность сети и повысить скорость передачи данных.
Однако, слишком большой размер окна может привести к переполнению буфера получателя и возникновению потери пакетов. Это может вызвать снижение производительности и повышение задержки передачи.
Оптимальный размер окна TCP зависит от различных факторов, включая задержку сети и пропускную способность. Операционные системы и сетевое оборудование могут автоматически настраивать размер окна TCP для достижения наилучшей производительности.
Как работает TCP windows size?
TCP window size (размер окна TCP) определяет количество данных, которые могут быть переданы между отправителем и получателем перед получением подтверждения (ACK) сигнала о приёме данных. Этот параметр влияет на скорость передачи данных и эффективность соединения.
В начале соединения отправитель и получатель договариваются о размере окна TCP, учитывая максимальную пропускную способность сети и задержки. Обычно, в этом процессе используется алгоритм «желаемого окна TCP» (TCP window scaling). Окно TCP может быть фиксированного размера или может настраиваться динамически в зависимости от условий сети.
Когда отправитель посылает данные получателю, он увеличивает размер окна TCP, указывая, сколько данных он может принять. Получатель передает это значение отправителю, чтобы тот знал, какой объем данных передать без получения подтверждения. Если размер окна TCP маленький, отправитель будет отправлять данные по мелким пакетам и ждать подтверждений, что может приводить к задержкам и снижению скорости.
Один из способов улучшить скорость соединения — увеличить размер окна TCP. Однако, это может привести к проблемам с переполнением буфера получателя или потерей данных при большом объеме передачи. Для предотвращения таких ситуаций TCP использует механизм подтверждения пакетов (ACK), чтобы отправитель знал, что данные были успешно доставлены.
Размер окна TCP является важным параметром для оптимизации производительности TCP-соединения. Правильная настройка размера окна TCP может улучшить скорость передачи данных и снизить задержку в сети. Однако, необходимо учитывать особенности сети, объем передаваемых данных и потенциальные проблемы с перегрузкой.
Зачем нужно управление TCP window size?
Управление TCP window size крайне важно для оптимизации скорости и производительности соединения. Правильное настройка размера окна позволяет эффективно использовать пропускную способность сети и минимизировать задержки при передаче данных.
Основная цель управления размером окна TCP – обеспечить оптимальную пропускную способность соединения, максимальную надежность и эффективность передачи данных.
При передаче данных TCP-соединение делится на маленькие блоки (пакеты). Каждый пакет подтверждается получателем, чтобы поддерживать надежность передачи. TCP window size позволяет отправителю передавать несколько блоков данных без подтверждения, что сокращает количество необходимых подтверждений и уменьшает время ожидания передачи данных.
Если размер окна TCP слишком мал, то отправитель будет вынужден ждать подтверждения после каждого переданного блока данных, что существенно замедляет скорость передачи. В то же время, слишком большой размер окна может привести к переполнению буфера устройства, что может вызвать потерю пакетов и снижение производительности.
Управление размером окна TCP включает в себя настройку сторон отправителя и получателя, чтобы они динамически адаптировали размер окна в зависимости от изменяющихся условий сети. Например, при отрицательном отклике сети размер окна уменьшается, а при положительном – увеличивается, чтобы эффективно использовать доступную пропускную способность.
Правильная настройка и управление TCP window size является одним из факторов, определяющих производительность TCP-соединения. При правильной настройке размера окна можно достичь высокой скорости передачи данных, минимальных задержек и надежной работы соединения.
Как влияет TCP windows size на скорость соединения?
Если TCP window size установлен слишком маленьким, это может привести к низкой скорости передачи данных. Это происходит из-за того, что отправитель должен подождать подтверждения от получателя перед отправкой следующей порции данных. Таким образом, маленький TCP window size приводит к меньшему потоку данных и, как результат, к меньшей скорости передачи.
С другой стороны, если TCP window size слишком большой, это может вызвать перегрузку сети и возникновение задержек. Большой TCP window size позволяет отправителю отправлять большие порции данных без ожидания подтверждения. Однако, если получатель не может обработать такой объем данных быстро, это может привести к переполнению его буфера и замедлению общей скорости соединения.
Оптимальный размер TCP window size зависит от различных факторов, включая пропускную способность сети, количество пакетов, маршрутизацию и задержки. Часто этот параметр автоматически определяется операционной системой или устройством, но в некоторых случаях пользователь может настроить его вручную для оптимизации скорости соединения.
| Маленький TCP window size | Большой TCP window size |
|---|---|
| Медленная скорость передачи данных | Потенциальная перегрузка сети и возникновение задержек |
| Ожидание подтверждения после каждой порции данных | Отправка больших порций данных без ожидания подтверждения |
| Низкая эффективность использования доступной пропускной способности сети | Потенциальное переполнение буфера и замедление общей скорости соединения |
В целом, правильная настройка TCP window size может значительно повлиять на скорость соединения TCP. Она должна оптимизироваться для конкретных условий сети с целью достижения максимальной производительности и избежания проблем, связанных с перегрузкой сети или задержками.
Transmission Control Protocol (TCP) is a fundamental protocol used in computer networks to ensure reliable data transmission. One crucial aspect of TCP performance is throughput, which measures the rate at which data can be transferred across a network. Understanding TCP throughput calculations is essential for optimizing network efficiency and ensuring smooth data flow. This article will delve into the concept of TCP throughput, explain the factors affecting it, and present methods for calculating and maximizing throughput.
-
Understanding TCP Throughput
TCP throughput refers to the amount of data that can be transmitted over a network in a given time frame. It is measured in bits per second (bps) and is influenced by various factors, including network bandwidth, latency, packet loss, and the TCP window size.
Network Bandwidth:
The available bandwidth is the maximum data rate that the network can support. It is typically measured in Mbps (Megabits per second) or Gbps (Gigabits per second). The network bandwidth serves as a theoretical upper limit for the TCP throughput.
Latency: Latency represents the time it takes for a data packet to travel from the source to the destination. It is usually measured in milliseconds (ms). Higher latency can impact TCP throughput, especially for applications that require low response times.
Packet Loss: Packet loss occurs when data packets are dropped during transmission. It can be caused by network congestion or errors in the network. Packet loss can significantly reduce TCP throughput and result in retransmissions, affecting overall performance.
TCP Window Size: The TCP window size determines the amount of data a sender can transmit before receiving an acknowledgment from the receiver. A larger window size can improve throughput by allowing more data to be sent before waiting for acknowledgment.
-
Calculating TCP Throughput
TCP throughput can be estimated using the following formula:
Throughput (bps) = TCP Window Size (bits) / Round-Trip Time (seconds)
The round-trip time (RTT) is the time it takes for a small data packet to travel from the sender to the receiver and back. It includes both the time taken for data transmission and the acknowledgment to return.
Example:
Let’s consider a TCP connection with a TCP window size of 64,000 bits and an RTT of 0.2 seconds.
Throughput = 64,000 bits / 0.2 seconds = 320,000 bps
-
Factors Affecting TCP Throughput
a. Bandwidth Delay Product (BDP):
The BDP is the maximum amount of data that can be in transit on the network at any given time. It is calculated by multiplying the bandwidth (in bps) by the round-trip time (in seconds). The TCP window size should be set to a value close to the BDP to achieve optimal throughput.
b. Congestion Window (CWND):
The CWND is dynamically adjusted by TCP to control the amount of data that can be sent before waiting for acknowledgments. It helps to avoid network congestion. When the CWND is small, the throughput may be limited, but it increases as the CWND grows.
c. TCP Slow Start:
During the initial phase of a TCP connection, the sender starts with a small CWND and increases it exponentially. This process, called slow start, helps avoid overwhelming the network with too much data at once.
-
Methods to Maximize TCP Throughput
a. Increasing TCP Window Size:
By increasing the TCP window size, more data can be sent before waiting for acknowledgments. However, setting the window size too large can lead to congestion and packet loss. Balancing the window size with the BDP is crucial for optimizing throughput.
b. Path MTU Discovery:
Path Maximum Transmission Unit (MTU) discovery helps determine the largest packet size that can be transmitted across the network without fragmentation. Using the optimal MTU size can reduce overhead and improve throughput.
c. TCP Offload Engines (TOE):
TOEs are specialized hardware components that handle TCP processing, relieving the burden from the main CPU. This can improve overall system performance and, in turn, enhance TCP throughput.
d. Quality of Service (QoS) Implementation:
QoS mechanisms prioritize specific traffic types, ensuring critical data receives sufficient network resources. This prevents congestion and packet loss, leading to better throughput for prioritized applications.
Let’s explore more examples of TCP throughput calculations in different scenarios:
Example 1:
High Bandwidth, Low Latency Connection Consider a scenario where you have a high-speed network connection with a bandwidth of 1 Gbps (1,000,000,000 bps) and a low latency of 5 milliseconds (0.005 seconds).
Let’s calculate the TCP throughput using the formula:
Throughput = TCP Window Size / Round-Trip Time
Suppose the TCP window size is set to 1,048,576 bits (128 KB).
Throughput = 1,048,576 bits / 0.005 seconds ≈ 209,715,200 bps or 209.7 Mbps
In this example, the high bandwidth and low latency result in a significant TCP throughput, allowing for fast data transmission.
Example 2:
TCP Throughput with High Packet Loss Now, let’s consider a scenario where the network experiences high packet loss, which adversely affects TCP throughput. Suppose we have a bandwidth of 100 Mbps (100,000,000 bps), a round-trip time of 50 milliseconds (0.05 seconds), and a TCP window size of 32,768 bits (4 KB). Due to network congestion, 10% of the packets are lost during transmission.
Effective TCP Window Size = TCP Window Size * (1 – Packet Loss Percentage) Effective TCP Window Size = 32,768 bits * (1 – 0.10) = 29,491.2 bits (approximately 3.68 KB)
Throughput = Effective TCP Window Size / Round-Trip Time
Throughput = 29,491.2 bits / 0.05 seconds ≈ 589,824 bps or 0.59 Mbps
The high packet loss significantly reduces the effective TCP window size and, consequently, the throughput.
Example 3:
Impact of TCP Window Size on Throughput Let’s examine how different TCP window sizes affect throughput with a 10 ms round-trip time and a bandwidth of 100 Mbps.
a. TCP Window Size = 64,000 bits (8 KB)
Throughput = 64,000 bits / 0.01 seconds = 6,400,000 bps or 6.4 Mbps
b. TCP Window Size = 128,000 bits (16 KB)
Throughput = 128,000 bits / 0.01 seconds = 12,800,000 bps or 12.8 Mbps
c. TCP Window Size = 256,000 bits (32 KB)
Throughput = 256,000 bits / 0.01 seconds = 25,600,000 bps or 25.6 Mbps
d. TCP Window Size = 512,000 bits (64 KB)
Throughput = 512,000 bits / 0.01 seconds = 51,200,000 bps or 51.2 Mbps
In this example, increasing the TCP window size results in a linear improvement in throughput. A larger window size allows for more data to be transmitted before waiting for acknowledgments, effectively utilizing the available bandwidth.
Conclusion
TCP throughput calculations are crucial for understanding and optimizing network performance. By considering different examples with varying network conditions and TCP settings, network administrators can fine-tune their systems to achieve the best possible throughput. Improving TCP throughput leads to faster data transfers, reduced response times, and enhanced overall network efficiency.
Lesson Contents
TCP (Transmission Control Protocol) is a connection oriented protocol which means that we keep track of how much data has been transmitted. The sender will transmit some data and the receiver has to acknowledge it. When we don’t receive the acknowledgment in time then the sender will re-transmit the data.
TCP uses “windowing” which means that a sender will send one or more data segments and the receiver will acknowledge one or all segments. When we start a TCP connection, the hosts will use a receive buffer where we temporarily store data before the application can process it.
When the receiver sends an acknowledgment, it will tell the sender how much data it can transmit before the receiver will send an acknowledgment. We call this the window size. Basically, the window size indicates the size of the receive buffer.
Typically the TCP connection will start with a small window size and every time when there is a successful acknowledgement, the window size will increase. Here’s an example:
Above we have two hosts, the host on the left side will send one segment and the host on the right side will send an acknowledgment in return. Since the acknowledgement was successful, the windows size will increase:
The host on the left side is now sending two segments and the host on the right side will return a single acknowledgment. Everything is working fine so the window size will increase even further:
The host is now sending four segments and the host on the right side responds with a single acknowledgment.
In the example above the window size keeps increasing as long as the receiver sends acknowledgments for all our segments or when the window size hits a certain maximum limit. When the receiver doesn’t send an acknowledgment within a certain time period (called the round-trip time) then the window size will be reduced.
When an interface has congestion then it’s possible that IP packets are dropped. To deal with this, TCP has a number of algorithms that deal with congestion control. One of them is called slow start.
Congestion occurs when the interface has to transmit more data than it can handle. It’s queue(s) will hit a limit and packets will be dropped.
With TCP slow start, the window size will initially grow exponentially (window size doubles) but once a packet is dropped, the window size will be reduced to one segment. It will then grow exponentially again until the window size is half of what it was when the congestion occurred. At that moment, the window size will grow linearly instead of exponentially.
When an interface gets congested, it’s possible that all your TCP connections will experience TCP slow start. Packets will be dropped and then all TCP connections will have a small window size. This is called TCP global synchronization. Here’s what it looks like:
The orange, blue and green lines are three different TCP connections. These TCP connections start at different times and after awhile, the interface gets congested and packets of all TCP connections are dropped. What happens is that the window size of all these TCP connections will drop to one and once the interface congestion is gone, all their window sizes will increase again.
The interface then gets congested again, the window size drops back to one and the story repeats itself. The result of this is that we don’t use all the available bandwidth that our interface has to offer. If you look at the dashed line you can see that we the average interface utilization isn’t very high.
To prevent global synchronization we can use RED (Random Early Detection). this is a feature that drops “random” packets from TCP flows based on the number of packets in a queue and the TOS (Type of Service) marking of the packets. When packets are dropped before a queue is full, we can avoid the global synchronization.
The end result will look similar to this:
When we use RED, our average interface utilization will improve.
Now you have an idea what the TCP window size is about, let’s take a look at a real example of how the window size is used. We can use wireshark for this.
Wireshark Captures
To examine the TCP window size I will use two devices:
The device on the left side is a modern computer with a gigabit interface. On the right side, we have a small raspberry pi which has a FastEthernet interface. The raspberry pi is a great little device but it’s cpu / memory / ethernet interface are limited. To get an interesting output, I will copy a large file through SSH from my computer to the raspberry pi which will be easily overburdened.
Here’s what happened, take a look at this picture:
In the graph above you can see the window size that was used during this connection. The file transfer started after about 6 seconds and you can see that the window size increased fast. It went up and down a bit but at around 30 seconds, it totally collapsed. After a few seconds it increased again and I was able to complete the file transfer. Let’s take a closer look at this file transfer, which starts with the three way handshake:
My fast computer uses 10.56.100.1 and the raspberry pi uses 10.56.100.164. Above you can see that in the SYN,ACK message that the raspberry pi wants to use a window size of 29200. My computer wants to use a window size of 8388480 (win=65535 * ws=128) which is irrelevant now since we are sending data to the raspberry pi.
After a few packets, the window size of the raspberry pi looks like this:
Above you can see that the window size has increased to 132480. Originally the window size is a 16 bit value so the largest window size would be 65535. Nowadays we use a scaling factor so that we can use larger window sizes.
At around the 10 second mark the window size decreased. Here’s what happened:
The raspberry pi seems to have trouble keeping up and its receive buffer is probably full. It tells the computer to use a window size of 26752 from now on. The computer sends 18 segments with 1460 bytes and one segment of 472 bytes (26752 bytes in total). The last packet shows us “TCP Window Full” message. This is something that wireshark reports to us, our computer has completely filled the receive buffer of the raspberry pi.
Once the raspberry pi has caught up a bit and around the 30 second mark, something bad happens. Take a look at the wireshark capture below:
Above you can see that the raspberry pi sends an ACK to the computer with a window size of 0. This means that the window size will remain at 0 for a specified amount of time, the raspberry pi is unable to receive any more data at this moment and the TCP transmission will be paused for awhile while the receive buffer is processed.
Here’s the actual packet:
Above you can see that the window size is now 0. Once the receive buffer has been processed, the raspberry pi will send an ACK with a new window size:
The window size is now only 25600 bytes but will grow again. The rest of the transmission went without any hiccups and the file transfer completed.
Conclusion
You have now seen how TCP uses the window size to tell the sender how much data to transmit before it will receive an acknowledgment. I also showed you an example of how the window size is used when the receiver is unable to process its receive buffer in time.
UDP, unlike TCP is a connectionless protocol and will just keep sending traffic. There is no window size, for this reason you might want to limit your UDP traffic or you might see starvation of your TCP traffic when there is congestion.
I hope you have enjoyed this lesson, if you have any more questions feel free to leave a comment in our forum.
I was reading up on TCP recently when I came across the term “Window size”, which also reminded me of another term I came across earlier, “MTU”.
I briefly understood that these 2 terms dictate how quickly data can be transferred between 2 machines, but what exactly are the differences?
Here is a very brief explanation on it.
What is window size?
Window size is a TCP header value which controls the flow of data. The header space for this value is 2 bytes long, which translates to a maximum value of 65535 bytes. This value is OS/TCP stack dependent.
What does it do?
Imagine you own a brewery and is currently tasked with transferring a huge tank of beer to your customer’s own beer tank.
Instead of being able to pump the beer directly into the other tank, your customer can only receive it with a pail before transferring it to the main tank.
The size of this pail is the window size.
I used pail as an example but you can imagine it being a cup if the window size is even smaller.
Now think about the amount of round trips required to completely transfer the beer over. Throw in the latency between each transfer and we can easily see how this can become a bottleneck.
Window scaling (optional)
For modern client-server communications, 65535 bytes wouldn’t cut it.
Thankfully, there’s the window scale option and is only sent with SYN packet.
This serves as a multiplier for the window size, which means a much larger buffer to hold the data.
Using the beer transfer analogy again, it’s like upgrading the pail to a cement truck.
Caveat: both server and client have to support this option, else it wouldn’t be available for use.
How does this differ from MTU?
MTU stands for Maximum Transmission Unit.
We can view the entire data transfer process as a combination of a few entities: server, client and the pipe connecting them.
The MTU determines the size of the pipe whereas window size determines the size of buffer at both ends.
Assuming MTU is 1500 bytes and the entire payload is 15000 bytes, there will be a total of 10 exchanges needed for entire transfer to complete.
Using Wireshark, we can see how MTU (1500 bytes) limits the TCP segment len, and also how these segments are finally assembled.
When performing analysis using Wireshark, do note that because window scale option is only sent with SYN packet, failing to capture this packet will result in Wireshark being unable to determine the “actual” window size and thus affect the analysis.
More info: https://networkengineering.stackexchange.com/questions/54107/how-can-a-tcp-window-size-be-allowed-to-be-larger-than-the-maximum-size-of-an-et