As QUIC is based on UDP, is the following entry correct?
_443._udp.example.com. 300 IN TLSA 1 0 1 HASH...
Related
We found a weird problem in our test, when sending a http2 packets, even the total data is not very big, we found the single packet will be splitted into 2 or 3 packets, 1 with header and 1 or 2 packet with Json data. Could any know which setting could solve this problem to put them in one single packet when size allowed. Thanks a lot.
I wonder about the differences I found regarding HTTP Client implementation,
There's options to choose HTTPClient 4 or Java
But for a simple case (www.google.com) Java implementation always show 0 in connect time and sent bytes Sampler results:
Connect Time: 0
Sent bytes:0
While HTTPClient 4 return different values each time as:
Connect Time: 100
Sent bytes:117
Request body is the same
GET http://www.google.com/
GET data:
[no cookies]
But Request Header differ while HttpClient sends also Host and User-Agent
Connection: keep-alive
Host: www.google.com
User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_25)
Is there a valid reason for these differences?
EDIT
Just to make it more confusing, when choosing empty implementation (should use default) the connect time is always 0 but Sent bytes is never 0
Connect Time: 0
Sent bytes:117
Java and HttpClient are 2 different implementations that can be used by HTTP Request.
The java one is less rich than hc4 and for example it does not implement :
sent bytes metric computation
connection time metric
kerberos authentication
There are also other features missing in Java implementation.
When you select empty, the value in property «jmeter.httpsampler » is used, by default it’s hc4.
I would like to use five TCP and five UDP streams (sending and receiving) in parallel on a single host, where the UDP traffic consists of video, and the TCP traffic is arbitrary. How do I use both transport layers in parallel on the same node?
In INET 3.0.0 there is an example nclients in examples\inet directory. It could be a good start point to prepare your model.
As long as the TCP and UDP traffic is independent, you can easily install several UDP and TCP applications at the same time in the same host. Something like this:
**.cli[*].numTcpApps = 2
**.cli[*].tcpApp[0].typename = "TelnetApp"
**.cli[*].tcpApp[1].typename = "TCPBasicClientApp"
**.cli[*].numUdpApps = 2
**.cli[*].udpApp[0].typename = "UDPVideoStreamSvr"
**.cli[*].udpApp[1].typename = "UDPVideoStreamSvr"
// ... further cofiguration of the applications
I'm trying to understand the TCP session. I tested a connection using TCP and I realise that initial the header options were with 20 bytes, but after the first ACK the header options were with 12 bytes.
Why the change? Because there isn't options available?
Some TCP options are only sent with the SYN packet:
Maximum segment size
Window scale
Select acknowledgement
TCP Alternate Checksum request
Looking at one of my network traces, the TCP header was 4 bytes larger in the SYN packet because of the maximum segment size option. You could use Wireshark to see which options are being sent in your traffic.
The Wikipedia page has more detail.
I am playing with multicast these days and I run into some odd things that I do not understand.
I create a chat multicast clients and everything seems to work ok. After that I read some linux documentation and figured out that by pinging the 224.0.0.1 should return me reply from all nodes that joined to some multicast group. I tried that on xp and on win7 machine. The behavior is the same on both of them. It seems that my client only joins to the group I defined (224.0.19.1). It does not join the 224.0.0.1 group.
From wireshark:
[source ip] 224.0.0.22 IGMPv3 54 Membership Report / Join group 224.0.19.1 for any sources
And here is how i set my socket:
IPEndPoint ipep = new IPEndPoint(IPAddress.Any, int.Parse(port));
m_socket.Bind(ipep);
IPAddress ip = IPAddress.Parse(mcastGroup);
m_socket.SetSocketOption(
SocketOptionLevel.IP, SocketOptionName.AddMembership,
new MulticastOption(ip, IPAddress.Any));
Then i checked in netsh:
C:\Users\user1>netsh interface ip show joins
Interface 1: Loopback Pseudo-Interface 1
Scope References Last Address
---------- ---------- ---- ---------------------------------
0 2 Yes 239.255.255.250
Interface 11: LAN
Scope References Last Address
---------- ---------- ---- ---------------------------------
0 0 Yes 224.0.0.1
0 1 Yes 224.0.0.252
0 1 Yes 224.0.19.1
0 1 Yes 230.230.230.230
0 2 Yes 239.255.255.250
Interface 15: Local Area Connection* 9
Scope References Last Address
---------- ---------- ---- ---------------------------------
0 0 Yes 224.0.0.1
And as you can notice there is no reference to the 224.0.0.1 address.
Of course I did turn off the firewall on both machines.
Now the question is: Is this something not supported by windows? Not supported by .NET? Did I forget to implement something? I would appreciate any help. Thanx.
I spent some time now on investigation this issue and I decided to share what I learned.
As soon as you bind to some multicast group your reference count is incremented. References to 224.0.0.1 is always 0 as it is not possible to bind into this group (at least not on win7).
It seems that multicast ping is disabled on windows. I did not find the answer to that, but I found out that my HP printer is replying on ping 224.0.0.1.
D:\tools>ping 224.0.0.1
Pinging 224.0.0.1 with 32 bytes of data:
Reply from 10.13.72.103: bytes=32 time<1ms TTL=64
Reply from 10.13.72.103: bytes=32 time<1ms TTL=64
Reply from 10.13.72.103: bytes=32 time<1ms TTL=64
Reply from 10.13.72.103: bytes=32 time<1ms TTL=64
There is another option to check if someone is using multicast address and in which group they are. By running igmpquery tool, you get the membership report by all nodes. The tool actually sends an IGMP general query on 224.0.0.1 address, and after that get the response from all nodes:
Source Destination Protocol Length Info
10.11.72.28 224.0.0.1 IGMPv2 60 Membership Query, general
10.11.72.12 224.0.0.252 IGMPv2 60 Membership Report group 224.0.0.252
10.11.72.12 239.255.255.250 IGMPv2 60 Membership Report group 239.255.255.250
10.11.72.28 224.0.19.1 IGMPv2 46 Membership Report group 224.0.19.1
10.11.72.254 224.0.0.2 IGMPv2 60 Membership Report group 224.0.0.2
10.11.72.103 224.0.0.251 IGMPv1 60 Membership Report
The node will respond only if it's listening on some multicast address. The win node can join the 224.0.0.1 group, as long as it is capable of receiving IGMP requests. This can be disabled by setting the registry value IGMPLevel to 0.
By that I explained myself all the questions. The only thing that still bothering me, is that I did not found any official documentation that multicast ping is not supported on windows. Well at list not fully, as it can send the ping requests, but can not send an echo.
it's a very old post but it still does not have an accepted answer. I think we can find the answer on the "https://tldp.org/HOWTO/Multicast-HOWTO-7.html" page, in the section "IGMP version 1.". It states
No reports are sent for the all-hosts group. Membership in this group
is permanent.
Multicast addresses are not assigned to individual machines, so you
can't ping them. Multicast addresses are "groups" to which individual
machines "subscribe."