[Chrome] initial connetcion or stalled too delay

부동산 전자계약 플랫폼을 개발하던중 이상한 현상이 발견됐습니다.

QA용으로 띄운 서비스 응답이 chrome을 제외한 브라우저에서만 빠르다는 겁니다. chrome도 한번 응답을 받은 뒤 응답이 빠르다, 새 브라우저에 다시 띄우면 응답이 느렸었습니다. pc chrome에서만 느리니 미치고 팔짝 뛸 노릇이었습니다.

 

ip로 접근하면 문제가 없어, 처음에는 도메인 서비스(cafe24, 가비아)문제라 생각했습니다. 그런데 이전 배포 서비스들과 동일한 방식으로 도메인 서버를 셋팅했고, 그나마 차이는 'default vpc vs custom vpc'뿐이었습니다.

*default는 기본 vpc/subnet, custom은 vpc/subnet/route table등등 자체 설계및 셋팅한 경우입니다.

 

처음부터 다시 본다는 마음가짐으로 아래 절차를 걸쳤습니다.

 

```````````````````

 

1) chrome dev-tool 체크

일단 chrome dev-tool의 network tab을 보니 아래와 같은 상태였습니다.

응답 결과1

응답 결과2

 

 

stalled(중단됨), initial connetcion(초기 연결)부분이 1.3m정도 늦어져 응답이 늦어지고 있었습니다. 요청/응답 영역은 front/back 자원과 코드 상태에 영향을 받지만,  연결 시작 영역은 다른 문제이기에 좀더 찾아 봤습니다.

 

2) network handshake?

공식 문서를 보니 연결 시작 영역은 network handshake or proxy와 관련된다 말하고 있었고, network handshake은 tcp통신시 client-server간 세션을 미리 수립하는 과정으로 알게 됐습니다. 연관있어 보이는데, 조금더 디테일한 분석이 필요했었습니다.

 

3) aws route table?

aws elb설정이 잘못되 비슷한 상황이 있었다는 글을 봐, elb 설정을 다시 확인했습니다. 그러다 elb가 향하는 서브넷 두개중 한 서브넷이 public route-table이 아닌, private route-table로 설정되 있음을 발견했습니다. 수정하니 바로 빨라지더라구요!

*internet facing elb는 public subnet에 있어야합니다

 

4) 결론

subnet설정시 public/private은 route table로 결정된다.

 

이상입니다

 

 

참고 자료:

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-manage-subnets.html