트래픽이 많이 발생한 이유는 굉장히 여러가지가 있겠지만

일단 정상트래픽이냐 / 비정상트래픽이냐를 확인 해봐야 할 듯 싶습니다.

 

평소에는 10~20Mbps 인데 특정시간에 100Mbps까지 치솟았다.

 

sflow에서 확인시

서버의 80포트에서 외부로 다량의 트래픽 발생하였다.

 

딱 봐도 같은 대역의 여러 아이피에서 트래픽이 발생된거보면 비정상 트래픽이다. 아이피 확인해보면 역시나 해외 아이피.

 

이제보니 서버의 어세스로그가 꺼져있다... 로그 분석까지 해서 올리고자 했으나....
음.. 경험상으로 볼 때 해당 아이피들로 어세스로그 분석해보면 캡챠등의 스팸개시글 등록 방지 기능이 없는 게시판에 무작위로 비아그라같은 스팸 게시글이 올라가 있는 경우가 있었다. 기억나는게 이거 말고는 .. 

 

조치방법으로는 앞서 말한것처럼 캡챠등의 스팸방지 기능을 넣어주던가 해외아이피를 차단하던가(해외와 통신 없을경우)

위 질문을 친한 후배가 물어봐서 정리해봐야겠습니다.

 

IT 면접시 자주 나온다고하는 naver.com 혹은 google.com 등을 접속할 경우 어떤 경로를 통해 어떤 프로세스를 통해 어떤 동작원리로 접속이 될까요" 라는 질문이 면접관분들께서 적잖게 하시는것 같습니다. 


어떤 분야던 지원자가 아는 범위를 설명하기에 지원자의 수준?역량?을 파악하기에 좋은 질문이라고 합니다.

PS.
DNS영역이든 http/https 프로토콜 영역등등 앞서 말씀드린것처럼 개발자/네트웤/서버등 디테일한부분은 다루는데 한계가 있기에 빠진부분이 있다면 코멘트 남겨주실 경우 정말 감사하겠습니다.

 


각설하고 PC에 크롬을 실행하고 naver.com 을 타이핑할 경우 크게 PC > 네트워크 > 서버 > 네트워크 > PC 일 것 같다.

 

논리적 플로우 : 브라우저 > PC 설정 > DNS > TCP > 서버 설정 
물리적 플로우 : PC > 허브 > PC가 속해있는 ISP 네트워크 > 서버가 속해있는 ISP 네트워크 > naver 백본 > naver 스위치 > naver 홈페이지 접속에 필요한 서버들 


1.브라우저 크롬 실행
1-1.크롬 브라우저 실행, 크롬 브라우저 실행에 필요한 프로세스(브라우저, 렌더러, 플러그인, GPU)가 실행되고 OS에서 프로세스가 작업 할 메모리 할당, 그에 따른 프로세스별 쓰레드 실행
크롬의 경우(브라우저마다 다름)프로세스 모델이 4가지(process per site instance / process per site / process per tab / single porcess)가 있다. 그중 프로세스 퍼 탭(탭마다 프로세스를 할당)했으나 작년초(2019년)부터는 프로세스 퍼 사이트(사이트마다 프로세스)를 할당한다. ###사이트 별 프로세스라면 사이트 하나가 응답이 없을 경우 다른 탭의 동일 사이트도 응답이 없을것이고 탭 별 프로세스라면 하나의 탭의 사이트가 응답이 없더라도 다른 탭의 사이트는 응답 가능
참고로 process per site instance(사이트 별 프로세스)와 process per site(사이트 당 프로세스) 가 살짝 헷갈릴 수 있는데 예를들어 naver.com에 두개 접속할 경우 process per site instance는 두개의 프로세스가 실행되고 process per site 는 1개의 프로세스가 실행된다.

각 모델별 설명 및 장단점은www.chromium.org/developers/design-documents/process-models 참고

 

2.URL 입력 > URL 문법에 맞는지 확인(ko.wikipedia.org/wiki/URL#cite_note-3)

https://naver.com 이 정확한 문법이다. 허나 naver.com 으로 접속해도 정상적으로 접속이 된다. 이는 각 브라우저의 아키텍쳐가 기본적으로 http://&https://(hsts에따라)에 접속되도록 설정이 돼 있기 때문
만약 문법이 맞지 않다면, 예를들어 네이버 라던가 녹색엔진등으로 접속시 브라우저 프로세스의 UI 스레드가 검색엔진으로 검색 진행 - 이 과정에서 dns lookup이 진행되기도 한다.

ps.여기서 검색어를 입력하고 엔터까지 안하고 입력만으로 검색어인지, URL인지 UI 스레드가 판단

 


3.URL 엔터 > 브라우저 프로세스의 UI 스레드가 네트워크 스레드 호출
먼저 브라우저에 도메인이 캐싱돼있는지 확인, 없을 경우 PC의 hosts 파일에 도메인 명시 돼 있는지 확인. 없다면 최종적으로  dns lookup 진행

 

4.먼저 PC에 설정돼있는 local dns에 질의
(local dns란 서버 혹은 PC의 네트워크 설정 때 설정하는 네임서버 정보로 보통 1/2차 구성, 캐쉬 dns라고도 불름)
ㄴ보통 저는 서버에 8.8.8.8(구글)이나 168.126.63.1(KT) 210.220.163.82(SK)등으로 설정.


---- 5번부터는 사실상 우리같은 일반인들이 컨트롤 할 일이 없다.-----

5.local dns에 없으면 local dns에서 root dns에게 TLD(Top-Level Doamin)정보를 질의(실제론 root dns 가 아닌 미러 서버에 질의) - 여기서부터는 반복적 쿼리
(root dns는 전세계에 13대밖에 없다. 이유는 더 늘어나면 512byte가 넘어서 tcp 통신을 한번 더 해야하기 때문. 그래서 root dns는 13대 밖에 없고 한국의 경우 기존에는 일본이 가지고 있는 root dns를 사용했는데 2002년도 root dns에 ddos 가 유입, 세계적으로 문제가 발생하여 우리나라에 2003년도에 미러 서버를 구축, 지금은 총 3대이고 kisa, kt, kinx에서 관리한다. 미러서버를 두는 이유는 첫째로 root dns 서버의 ddos, 두번째로는 해외 dns를 사용하지않고 국내의 미러 dns를 사용함에따라 속도 및 비용 절감)

6.root dns 는 TLD를 관리하는 TLD 네임서버 정보를 DNS서버에 응답

7. local dns는 다시 TLD dns에게 도메인 정보를 쿼리
8. TLD DNS는 도메인의 네임서버 정보를 local dns에 응답

9. local dns는 다시 도메인의 네임서버로 도메인 정보를 쿼리

10. 도메인의 네임서버는 도메인에 대한 정보를 local dns에게 전달

11. local DNS는 해당 정보를 로컬 캐시에 저장하고 호스트에게 도메인 정보를 응답

12. 사용자는 위 과정으로 얻은 IP 정보를 이용해 사이트에 접속






ㄴDNS

osi 7 layer
서버
ㄴ소스 config
ㄴ어플리케이션 config
ㄴ서버 config








브라우저 프로세스   주소 표시줄, 북마크 막대, 뒤로 가기 버튼, 앞으로 가기 버튼 등 애플리케이션의 "chrome" 부분을 제어한다. 네트워크 요청이나 파일 접근과 같이 눈에 보이지는 않지만 권한이 필요한 부분도 처리한다.
ㄴUI 스레드(브라우저 버튼 및 입력), 네트워크 스레드(네트워크단), 스토리지 스레드(파일 접근 제어)
렌더러 프로세스   탭 안에서 웹 사이트가 표시되는 부분의 모든 것을 제어한다.
플러그인 프로세스   웹 사이트에서 사용하는 플러그인(예: Flash)을 제어한다.
GPU 프로세스   GPU 작업을 다른 프로세스와 격리해서 처리한다. GPU는 여러 애플리케이션의 요청을 처리하고 같은 화면에 요청받은 내용을 그리기 때문에 GPU 프로세스는 별도 프로세스로 분리되어 있다.

 

 

 

 

---정리중

설명하기에 앞서. 이 글을 적는 이유는
1. 각각의 기능들에 대해 공식docs 를 참고하여(즉 정확하게) 최대한 디테일하게, 공부하기 위함 최대한 초심자에 맞춰(본인이 초심자이기에)설명
2. 추후 100% 까먹을테니 정리하기 위함
ps.기능 및 옵션들은 회사에서 사용되는 옵션들(회사에서 직접 개발된 모듈들은 설명X, 사내 WIKI에 기재)

 

참고 URL : 
http://nginx.org/en/docs/ngx_core_module.html

 

 

worker_processes / Context : main
실행할 워커 프로세스 갯수 정의 , cpu 코어 갯수( cat /proc/cpuinfo | grep proce|  wc -l)대로 하는게 좋다
ex) worker_processes 4; 
.4로 지정하는경우 아래와 같이 워커 프로세스 4개 실행됨
root     21554     1  0  2019 ?        00:08:31 nginx: master process /usr/local/nginx/sbin/nginx
nobody   40544 21554  0 10:31 ?        00:00:00 nginx: worker process
nobody   40545 21554  0 10:31 ?        00:00:00 nginx: worker process
nobody   40546 21554  0 10:31 ?        00:00:01 nginx: worker process
nobody   40547 21554  1 10:31 ?        00:00:04 nginx: worker process

The auto parameter is supported starting from versions 1.3.8 and 1.2.5.

 

worker_rlimit_nofile / context : main
워커 프로세스가 사용 할 수 있는 최대 파일 갯수, worker conntercions의 3~4배가 적당하다고 함, 
ex) worker_rlimit_nofile  32768;

worker_connections / context : events
하나의 워커 프로세스당 최대 동시 연결 수, 클라이언트와의 연결 뿐 아니라 모든 연결이 포함됨(즉 아파치/nginx 프록시로 연결돼있을 경우 클라이언트 > nginx 1개, nginx > apache 1개 총 2개의 커넥션이 사용됨)
OS의 최대 오픈 파일 갯수(cat /etc/security/limits.conf | egrep -i "soft|hard" | grep -v "#" )를 넘으면 안된다.

ex) worker_connections 8192;

 

server_tokens 
서버 response header 에 nginx 버전 활성화 여부, 보안상 off 추천
ex) server_tokens off; 

server_names_hash_max_size(
server name 의 최대 해시 사이즈 설정
ex) server_names_hash_max_size      2048;

server_names_hash_bucket_size

server name의 최대 버킷 사이즈 설정

ex) server_names_hash_bucket_size   256;

 

###해시와 버킷이란, nginx 에서는 어떻게 사용되는지 ?
먼저 hash 를 예를 들자면 nginx 의 vhost 설정하기 위해 server_name 이 아래와같이 여러개가 있을경우
server_name  test1.kr www.test1.kr
server_name  testtest2.kr www.testtest2.kr

server_name  t3.kr www.t3.kr

등등...
test1.kr www.test1.kr > aaaa1111
testtest2.kr www.testtest2.kr > bbbb2222
t3.kr www.t3.kr > cccc3333

  
위와같이 어떤 크기의 데이터든 일정한 크기의 고유 문자열로 변경한다. 따라서 어떠한 크기의 데이터든 일정한 크기의 고유 문자열과 1:1 매칭이 돼 있기 때문에 "testtest2.kr"를 불러오는것보다 bbbb2222를 불러오는게 더욱 빠르게 처리 된다. (암호화에도 도움이 되지만 엔진엑스에서는 암호화때문에 사용하는건 아닌듯?)
엔진엑스에서는
server_name, map 지시어, mime type, reqest header 문자열 등의 정적 데이터들을 빠르게 처리하기 위해 해쉬 테이블을 사용한다. 
해쉬 테이블은 해쉬 함수를 이용해서 키를 해쉬로 바꾸고 바꿔진 해쉬와 매칭된 value가 저장되있는 버킷들

즉 server_names_hash_max_size 는 test1.kr testtest2.kr 과 같은 키들의 사이즈라 생각하면 편하고
server_names_hash_bucket_size 는 vhost 들의 갯수라 생각하면 된다.

 

set_real_ip_from / real_ip_header

ex)
real_ip_header X-Forwarded-For;
set_real_ip_from 127.0.0.1;
set_real_ip_from 172.16.253.10;
set_real_ip_from 172.16.253.14;

프록시 사용할경우 실제 주소를 확인하기 위한 설정

 

map

공식 독스 설명에는 변수에 따라 값이 달라지는 변수를 생성 한다(string를 받아서 value 를 매핑) 라고 나와있다. 쉽게 말하면 특정 아이피,도메인,대역등을 변수로 지정(string) 후 그 변수들을 접속 허용, 차단 또는 지정된 변수는 로깅을 하지 않는다 등을 한다고 보면 될듯 하다.
ex)
https://sub0709.tistory.com/110

 

gzip

ex)
gzip                   on;
gzip_proxied           any;
gzip_http_version      1.1;
gzip_min_length        1100;
gzip_comp_level        5;
gzip_buffers           16 32k;
gzip_vary              on;
gzip_disable           "msie6|Yeti";


전송 데이터를 줄이기 위해 gzip 을 이용하여 리퀘스트를 압축하는 모듈

 

proxy
https://12bme.tistory.com/367 설명 잘 돼 있음

 

vts
https://blog.naver.com/ncloud24/221598840260

 

+ Recent posts