AT+CIPSEND , after prompt > , esp8266 LOST bytes working @1Mbit/s

[pweb.ing]

MY SETUP
I have my pc application using esp8266 with help of usb-uart converter and another pc app running as TCP server.
Esp is connected to a WiFi network and it is configured with 1Mbit/s baudrate.
I'm running a stress test in order to measure the maximum throughput for our next connected device. Applications are exchanging 1kbyte packets in ping pong way (every time one receive a packet, the peer send packet to other one)

ISSUE OBSERVED
after few seconds, I saw that esp stopped sending, waiting bytes after ">" prompt after at+cipsend request to send 1024 bytes.
My application sent 1024 bytes BUT esp counts less (something in the middle was lost): after sending other "filling" bytes, esp sent packet, I saw "send ok" message and i saw on other peer packet with missing bytes inside and filling bytes at the end.
I checked with oscilloscope on esp Rx pin and signal is perfect and also my oscilloscope decoded in right way all 1024 bytes.
NOTE: before issue, i saw previsious packet was sent and SEND OK arrived from esp.

MY ISSUE EXPLANATION
my understanding is esp don't have DMA on UART but it has 128 bytes hw fifo. @1Mbit/s it means 1,28ms of buffering.
I don't know how fw for AT commands is implemented, but it could be a challenge for the fw and bytes are lost for fifo overrun at driver level and high level code counted less bytes and had a buffer for next send with lost bytes in the middle.


What do you think? Is it a possible explanation?

MY NEXT ATTEMPT TO FIX ISSUE
I will configure esp uart with CTS RTS hw flow control (and also my application).
I hope fw inside esp will trigger fifo threshold and will assert RTS as high in the middle of packet data exchange and my application will slow sending avoiding fifo overflow.

Do you think this could fix? Or I'm in wrong and you can help me suggesting something else?

Thanks in advance

[pweb.ing]

UPDATE:
i did a mistake.
Uart settings of my esp was 1Mbit/s 8n1 with RTS enabled (instead of NO hw flow control) and my pc app had uart settings without hw flow control.
With this configuration, I saw with oscilloscope that RTS signal from esp had positive pulses, and when esp lost bytes, pulse was greater than 2ms.
So my explanation above seems correct, even issue was caused by wrong settings (hw flow control settings didn't match)
Instead, disabling hw flow control on esp, everything seems more stable, even I cannot know if it was critical on internal fifo usage.

So, I did some tests using ON BOTH sides, on esp and on my pc app, hw flow control enabled.
With this setup again everything worked fine, but I was able to verify that esp RTS had positive pulses but shorter than 300us, so it seems a good and stable result, for fifo usage.

Can someone confirm my analysis?