Hi, Thanks for the ideas, but we just use a self signed certificate. I am not really an expert with certificates, would there be any kind of lookup done to a certificate authority or other internet site with a self signed certificate ?
If so is there any way to disable it ? we are just using svn internaly in an small company and dont have a big IT department. regards Matthew J Fletcher > -----Original Message----- > From: Brian Brophy [mailto:brianmbro...@gmail.com] > Sent: 22 April 2011 16:39 > To: Matthew Fletcher; users@subversion.apache.org > Subject: Re: Slow initial repo access (https method) > > Is your trace below only showing traffic from client to SVN > server? If so, try grabbing all traffic from the client to > see what else may be going on. There are a couple features > of SSL which may explain this. > > First, does your certificate signing chain include > intermediary signers? An example would be something like > VeriSign Public Primary G3 > -> VeriSign International Root G5 -> Your Certificate. If so, the > server should have all signers in the chain available to it, > so that if the client needs them to verify the handshake, the > server can hand them down. If the client determines it needs > the intermediaries and the server does not have them, the > client may go out to the provider (ie, > VeriSign) and attempt to download the missing certificates in > order to perform the verification. > > Second, some SSL certificates include a configuration for a > revocation link. This is a location (typically a publicly > accessible URL) that the client can view on the certificate's > metadata, and if implemented, call out to the revocation > location in order to determine if the certificate the client > is attempting to handshake with (ie, your server cert) has > since been revoked by the signer. It is a mechanism for the > signer to "de-certify" a certificate that otherwise would be > ok (ie, start/end dates are within window, cn matches hostname, etc). > > Some thoughts, > Brian > > Matthew Fletcher wrote: > > Hi, > > > > We are using svn 1.6.16 on the server and have noticed that > there is a large pause in the inital https requests, (snip of > wireshark shown bellow). Basically it looks like this is a > server side issue but i am not sure where to look for logs (apache ?). > > > > 10.141.80.130 (server) > > 10.141.81.134 (client) > > > > No. Time Source Destination > Protocol Info > > 1 0.000000 10.141.81.134 10.141.80.130 > TCP 50186 > pcsync-https [SYN] Seq=0 Win=8192 Len=0 > MSS=1460 SACK_PERM=1 > > No. Time Source Destination > Protocol Info > > 2 0.000125 10.141.80.130 10.141.81.134 > TCP pcsync-https > 50186 [SYN, ACK] Seq=0 Ack=1 > Win=16384 Len=0 MSS=1460 SACK_PERM=1 > > No. Time Source Destination > Protocol Info > > 3 0.000166 10.141.81.134 10.141.80.130 > TCP 50186 > pcsync-https [ACK] Seq=1 Ack=1 Win=64240 Len=0 > > No. Time Source Destination > Protocol Info > > 4 0.000307 10.141.81.134 10.141.80.130 > TCP 50186 > pcsync-https [PSH, ACK] Seq=1 Ack=1 > Win=64240 Len=227 > > No. Time Source Destination > Protocol Info > > 5 0.013041 10.141.80.130 10.141.81.134 > TCP pcsync-https > 50186 [ACK] Seq=1 Ack=228 > Win=65308 Len=1460 > > No. Time Source Destination > Protocol Info > > 6 0.013068 10.141.80.130 10.141.81.134 > TCP pcsync-https > 50186 [PSH, ACK] Seq=1461 Ack=228 > Win=65308 Len=13 > > No. Time Source Destination > Protocol Info > > 7 0.013084 10.141.81.134 10.141.80.130 > TCP 50186 > pcsync-https [ACK] Seq=228 Ack=1474 > Win=64240 Len=0 > > No. Time Source Destination > Protocol Info > > 8 0.029234 10.141.81.134 10.141.80.130 > TCP 50186 > pcsync-https [PSH, ACK] Seq=228 Ack=1474 > Win=64240 Len=198 > > No. Time Source Destination > Protocol Info > > 9 0.033499 10.141.80.130 10.141.81.134 > TCP pcsync-https > 50186 [PSH, ACK] Seq=1474 Ack=426 > Win=65110 Len=266 > > No. Time Source Destination > Protocol Info > > 10 0.225080 10.141.81.134 10.141.80.130 > TCP 50186 > pcsync-https [ACK] Seq=426 Ack=1740 > Win=63974 Len=0 > > No. Time Source Destination > Protocol Info > > 11 15.123199 10.141.81.134 10.141.80.130 > TCP 50186 > pcsync-https [PSH, ACK] Seq=426 Ack=1740 > Win=63974 Len=485 > > No. Time Source Destination > Protocol Info > > 12 15.123238 10.141.81.134 10.141.80.130 > TCP 50186 > pcsync-https [PSH, ACK] Seq=911 Ack=1740 > Win=63974 Len=133 > > No. Time Source Destination > Protocol Info > > 13 15.123401 10.141.80.130 10.141.81.134 > TCP pcsync-https > 50186 [ACK] Seq=1740 Ack=1044 > Win=64492 Len=0 > > No. Time Source Destination > Protocol Info > > 14 15.124022 10.141.80.130 10.141.81.134 > TCP pcsync-https > 50186 [PSH, ACK] Seq=1740 > Ack=1044 Win=64492 Len=746 > > > > > > Note the giant 15 second wait between packets 10-11, and > then fast afterwards. > > > > See the slow packets 10-11 in full bellow; > > > > > > Frame 10: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) > > Ethernet II, Src: Dell_4e:1a:ce (00:1e:c9:4e:1a:ce), Dst: > > Dell_cf:17:71 (00:1e:c9:cf:17:71) Internet Protocol, Src: > 10.141.81.134 (10.141.81.134), Dst: 10.141.80.130 (10.141.80.130) > > Version: 4 > > Header length: 20 bytes > > Differentiated Services Field: 0x00 (DSCP 0x00: > Default; ECN: 0x00) > > Total Length: 40 > > Identification: 0x453c (17724) > > Flags: 0x02 (Don't Fragment) > > Fragment offset: 0 > > Time to live: 128 > > Protocol: TCP (6) > > Header checksum: 0x0000 [incorrect, should be 0xfe71] > > Source: 10.141.81.134 (10.141.81.134) > > Destination: 10.141.80.130 (10.141.80.130) Transmission Control > > Protocol, Src Port: 50186 (50186), Dst Port: pcsync-https > (8443), Seq: 426, Ack: 1740, Len: 0 > > Source port: 50186 (50186) > > Destination port: pcsync-https (8443) > > [Stream index: 0] > > Sequence number: 426 (relative sequence number) > > Acknowledgement number: 1740 (relative ack number) > > Header length: 20 bytes > > Flags: 0x10 (ACK) > > Window size: 63974 > > Checksum: 0xb73c [validation disabled] > > [SEQ/ACK analysis] > > > > > > Frame 11: 539 bytes on wire (4312 bits), 539 bytes captured (4312 > > bits) Ethernet II, Src: Dell_4e:1a:ce (00:1e:c9:4e:1a:ce), Dst: > > Dell_cf:17:71 (00:1e:c9:cf:17:71) Internet Protocol, Src: > 10.141.81.134 (10.141.81.134), Dst: 10.141.80.130 (10.141.80.130) > > Version: 4 > > Header length: 20 bytes > > Differentiated Services Field: 0x00 (DSCP 0x00: > Default; ECN: 0x00) > > Total Length: 525 > > Identification: 0x4546 (17734) > > Flags: 0x02 (Don't Fragment) > > Fragment offset: 0 > > Time to live: 128 > > Protocol: TCP (6) > > Header checksum: 0x0000 [incorrect, should be 0xfc82] > > Source: 10.141.81.134 (10.141.81.134) > > Destination: 10.141.80.130 (10.141.80.130) Transmission Control > > Protocol, Src Port: 50186 (50186), Dst Port: pcsync-https > (8443), Seq: 426, Ack: 1740, Len: 485 > > Source port: 50186 (50186) > > Destination port: pcsync-https (8443) > > [Stream index: 0] > > Sequence number: 426 (relative sequence number) > > [Next sequence number: 911 (relative sequence number)] > > Acknowledgement number: 1740 (relative ack number) > > Header length: 20 bytes > > Flags: 0x18 (PSH, ACK) > > Window size: 63974 > > Checksum: 0xb921 [validation disabled] > > [SEQ/ACK analysis] > > Data (485 bytes) > > > > 0000 17 03 01 01 e0 5b aa 54 59 c4 53 f1 31 5a c3 00 > .....[.TY.S.1Z.. > > 0010 9f b8 89 74 7e 6a ce 5a a0 34 02 dc 78 6b a3 2d > ...t~j.Z.4..xk.- > > 0020 64 2f 60 dc c6 80 00 3f 01 20 50 02 d2 4d 70 f2 > d/`....?. P..Mp. > > 0030 4f 9d 82 a6 3a cc 8f 18 3f a3 d7 0b ea 1d 33 1b > O...:...?.....3. > > 0040 84 b3 15 c2 5d de d5 6b 49 1a 72 a3 10 a2 8e b0 > ....]..kI.r..... > > 0050 9c 82 9a 65 f0 05 38 3b 7d d2 9b 5c 1b ed b6 85 > ...e..8;}..\.... > > 0060 d5 0d 17 9a 99 5c a4 18 ac 12 d5 7d 26 82 a3 b3 > .....\.....}&... > > 0070 d9 a2 66 07 52 d3 7f ea 26 69 f1 a5 ee a8 b9 21 > ..f.R...&i.....! > > 0080 b9 98 d2 a8 e6 05 30 2d a2 53 8b 0b 59 bd 6e ed > ......0-.S..Y.n. > > 0090 9a b6 4e 9e 7a 57 ad 16 bc 4e 6b f8 48 e3 d2 b3 > ..N.zW...Nk.H... > > 00a0 8f 19 2d e6 0a 06 bf 7f 71 e0 74 a2 8e fa 92 59 > ..-.....q.t....Y > > 00b0 7e 00 24 06 41 c6 f0 bc 74 f3 39 af 3c e3 34 20 > ~.$.A...t.9.<.4 > > 00c0 f4 35 9f 70 40 c6 95 2a 69 61 98 ff 58 52 5e 03 > .5.p@..*ia..XR^. > > 00d0 50 c1 60 d5 27 53 48 60 c4 1b e7 a6 49 1d 98 f0 > P.`.'SH`....I... > > 00e0 46 8c 25 b5 1f 7b 93 79 1b 52 02 e5 fd 9e 2c 6d > F.%..{.y.R....,m > > 00f0 8e ed 6f 6c f3 8e 72 1e 76 0f 7c c0 f9 61 00 1c > ..ol..r.v.|..a.. > > 0100 95 21 f8 f5 e1 32 bd 83 47 65 d2 f4 21 7e b0 20 > .!...2..Ge..!~. > > 0110 d6 45 48 30 a1 6b e8 e3 8e f0 58 ad f7 9e 5b ff > .EH0.k....X...[. > > 0120 86 63 fe d1 1b 0c bb af e1 85 e1 d8 13 f0 00 78 > .c.............x > > 0130 3a f6 de d6 77 40 be e8 e1 ab 4c e3 7c 7c ec 3d > :...w@....L.||.= > > 0140 4c 56 e9 42 11 cb 42 13 81 75 66 70 01 63 c5 40 > LV.B..B..ufp.c.@ > > 0150 fa 2e 39 86 64 ac 7a da 38 0e aa 15 62 b1 4f 6f > ..9.d.z.8...b.Oo > > 0160 f2 71 b8 12 64 f4 91 f2 1c 57 ae 15 05 20 42 2b > .q..d....W... B+ > > 0170 a3 6e 24 01 dc 8c fa b0 49 2f 5e 68 68 29 1d de > .n$.....I/^hh).. > > 0180 c6 dc 14 44 76 91 6b 4b ed 4f 65 77 43 a1 56 df > ...Dv.kK.OewC.V. > > 0190 4a 66 8d 00 e9 96 f7 3a 60 dd 5a 3e e7 4f a5 ae > Jf.....:`.Z>.O.. > > 01a0 6e 82 49 81 ce 4d a8 1e 2d 0d c6 ae 3e 5b ee 83 > n.I..M..-...>[.. > > 01b0 b0 29 72 91 48 57 54 72 f3 a1 59 46 cf ff dd 0b > .)r.HWTr..YF.... > > 01c0 95 ef 03 2b fe c0 4c 47 f1 cd e8 46 07 17 7c 1a > ...+..LG...F..|. > > 01d0 d8 d0 bc 68 b4 ca 07 ec 73 87 eb 34 93 e5 1f 42 > ...h....s..4...B > > 01e0 fa ce 60 11 f6 ..`.. > > > > > > any ideas why this packet takes so long to be created, or > what operation preceded it can caused the slowness ? > > > > > > regards, > > > > Matthew J Fletcher > > > > > > > ********************************************************************** > > Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK A company > > registered in England Reg. No. 4353634 > > Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437 > > Web: www.serck-controls.com Admin: p...@serck-controls.co.uk A > > subsidiary of Schneider Electric. > > > ********************************************************************** > > This email and files transmitted with it are confidential > and intended > > solely for the use of the individual or entity to whom they are > > addressed. If you have received this email in error please > notify the > > above. Any views or opinions presented are those of the > author and do > > not necessarily represent those of Serck Controls Ltd. > > > > This message has been scanned for malware by Mailcontrol. > > www.Mailcontrol.com > > >
