[
https://issues.apache.org/jira/browse/TS-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15313205#comment-15313205
]
Masaori Koshiba commented on TS-4324:
-------------------------------------
IMO, the root cause of this is definition of DATA frame length.
We define it 16K. And frame header length is 9. So frame payload length is 16K
- 9.
When origin send two 8KB or 16KB chunk, TS needs to divide it in 16K - 9 byte
and 9 byte frames.
On the other hand, the RFC says below in [4.1 Frame
Format](http://httpwg.org/specs/rfc7540.html#FrameHeader)
{noformat}
Length:
The length of the frame payload expressed as an unsigned 24-bit integer. Values
greater than 214 (16,384) MUST NOT be sent unless the receiver has set a larger
value for SETTINGS_MAX_FRAME_SIZE.
The 9 octets of the frame header are not included in this value.
{noformat}
So we can use 16K + 9 as DATA frame length. And it will fix this issue.
> Inefficient way of transferring data frames
> -------------------------------------------
>
> Key: TS-4324
> URL: https://issues.apache.org/jira/browse/TS-4324
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP/2
> Reporter: Bryan Call
> Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>
> ATS transfers data 8K - 9 bytes (http/2 header size) and then sends the 9
> bytes is couldn't write in a new frame that only has 9 bytes. This also
> happens if you bump up the buffer size to 16K.
> {code}
> [ 1.036] recv DATA frame <length=8183, flags=0x00, stream_id=13>
> [ 1.036] recv DATA frame <length=9, flags=0x00, stream_id=13>
> [ 1.259] recv DATA frame <length=8183, flags=0x00, stream_id=13>
> [ 1.259] recv DATA frame <length=9, flags=0x00, stream_id=13>
> [ 1.259] recv DATA frame <length=8183, flags=0x00, stream_id=13>
> [ 1.259] recv DATA frame <length=9, flags=0x00, stream_id=13>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
