Azure ExpressRoute 구성도

[ExpressRoute] 주요 네트워크 지점 설명

1. 고객 컴퓨팅 디바이스(: 서버 또는 PC)
2. 고객 Edge 라우터(CE)
3. 고객 Edge 라우터에 연결되는 공급자 Edge 라우터/스위치(PE)
4. Microsoft Enterprise Edge 라우터(MSEE)와 마주하는 PE. 이 문서에서는 PE-MSEE라고 합니다.
5. MSEE
6. 가상 네트워크 게이트웨이
7. Azure 가상 네트워크의 컴퓨팅 디바이스
 

고객사 집선L3(VRF) – 회선사업자 ASR(Active-Active) PE (Active-Standby) – MSEE vHub

 

* 서버 Logging설정이 되어있는지 점검하고, 특이사항이 있는지 확인 필요!!

1. OS 로그 설정

  • 시스템 로그 설정되어 있는지 확인하고, 장애 분석 및 시스템 문제 발생 시 확인이 가능하도록 필수 로깅이 설정되어있는지 확인한다.
  • 로그가 중복으로 설정되어, 로그가 과다 생성되고 있는지 확인
  • syslogd

       - /etc/syslog.conf, /etc/rsyslog.conf 파일로 로그형식 및 경로를 설정함

       - syslogd 데몬이 OS 로그를 기록함

  • rsyslog의 메인 설정화일은 /etc/rsyslog.conf 임. 이 화일에서 /etc/rsyslog.d/50-default.conf 을 불러와 추가적인 내용을 설정하며 설정화일에 대한 자세한 내용은 man rsyslog.conf 를 확인 

 

  • rsyslog관련 파일
관련파일  설명 
/etc/rc.d/init.rsyslog -rsyslogd 데몬을 동작시키는 스크립트
/etc/init.rsyslog.conf -rsyslogd 데몬 환경 설정 파일

/etc/sysconfig/rsyslog -rsyslogd

데몬 실행과 관련된 옵션설정파일

/sbin/rsyslogd
실제 rsyslog 데몬

 

2. OS 로그 특이사항 확인

  • syslogd에 설정한 로그파일에 OS로그가 정상적으로 기록되고 있는지 확인
  • kernel오류, emergency, alert, critical, error 레벨의 로그가 남지는 않는지 우선 확인 후 그 외 warning 이하 minor level의 로그를 확인함
  • 주요 로그파일
    • /var/log/messages
    • /var/log/cron
    •  /var/log/boot.log
    •  /var/log/dmesg
    • /var/log/kern.log
  • 기타 로그파일
    • /var/log/auth.log
    • /var/log/secure
    • /var/log/wtmp
    •  /var/log/utmp
    •  /var/log/xferlog
    •  /var/log/yum.log
    • /var/log/named.log

3. 자원 사용률 로깅 설정 여부 확인

  • 자원사용률이 로깅되고 있는 지 확인
  • polestar, ontune등 상용 SMS 툴이 없을 경우 nmon, perfmon 등으로 logging 설정이 되어있는지 확인
  • nmon 로깅 예시(Version에 따라 상세 옵션이 다를 수 있음)

4. 이상징후 발생 시 담당자에게 알림 여부 확인

  • 서버 자원사용률 임계치 초과, 서버로그 상 특이사항 발생 시 대시보드 또는 알람을 통해 담당자에게 전달되는지 확인

5. Log Level

  • syslog는 IETF의 RFC 5424 로 등록됨. RFC 5424에는 syslog 메시지를 인터넷 상으로 전달하는 방법을 기술
  • 메시지의 특성을 정의하는 facility와 severity중 facility는 메시지를 발생시킨 프로그램의 타입을 나타내는 값이며, severity는 메시지의 성격 또는 중요도를 나타냄. syslog에서는 이 값에 따라 로그 메시지를 어느 화일에 기록할지, 누구에게 이 사실을 알릴 것인지를 결정함
  • facility와 severity에 따라 어떤 화일에 로그를 쓸지에 대해, rsyslog의 경우 /etc/rsyslog.d/50-default.conf 에 정의되어 있다.

● /etc/rsyslog.conf 파일
※기본 형식
: facility.priority    action

형식 설명  
facility .일종의 서비스를 의미
.메시지를 발생 시키는 프로그램의 유형
 
priority .위험의 정도를 나타내며, 설정한 수준을 포함해서 높으면 메시지 보냄
.설정 앞에 = 사용의 경우 : 해당 수준(priority)의 위험도와 같은 경우에 메시지 보냄 
.설정 앞에 ! 사용의 경우 : 해당 수준(priority)만 제외 시킬때 사용
 
action .메시지를 보낼 목적지나 행동들에 관한 설정
.보통 파일명이나 아이디 들을 적음
 
규칙 .facility : 콤마(,) 사용
.facility.priority의 조함 : 세미콜론 (;) 사용
 

 

1) severity : 메시지의 성격 또는 중요도 -0~7 사이의 숫자로, 숫자가 낮을수록 심각한 문제라는 것을 내포함

Code Severity Keyword C code Description
0 Emergency emerg (panic) LOG_EMERG System is unusable.
1 Alert alert LOG_ALERT Action must be taken immediately.
2 Critical crit LOG_CRIT Critical conditions.
3 Error err (error) LOG_ERR Error conditions.
4 Warning warning (warn) LOG_WARNING Warning conditions.
5 Notice notice LOG_NOTICE Normal but significant condition.
6 Informational info LOG_INFO Informational messages.
7 Debug debug LOG_DEBUG Debug-level messages.

2) facility : 메시지를 발생시킨 프로그램의 타입(발생주체) -이벤트를 생성한 프로세스, 모듈, 프로토콜을 나타냄. 메일 시스템, 커널, 네트워크 등이 될 수 있음

Facility
Number
Keyword C code Facility Description
0 kern LOG_KERN kernel messages
1 user LOG_USER user-level messages
2 mail LOG_MAIL mail system
3 daemon LOG_DAEMON system daemons
4 auth LOG_AUTH security/authorization messages
5 syslog LOG_SYSLOG messages generated internally by syslogd
6 lpr LOG_LPR line printer subsystem
7 news LOG_NEWS network news subsystem
8 uucp LOG_UUCP UUCP subsystem
9 clock LOG_CRON clock daemon
10 authpriv LOG_AUTHPRIV security/authorization messages
11 ftp . FTP daemon
12 . . NTP subsystem
13 . . log audit
14 . . log alert
15 cron . clock daemon
16 local0 LOG_LOCAL0 local use 0 (local0)
17 local1 LOG_LOCAL1 local use 1 (local1)
18 local2 LOG_LOCAL2 local use 2 (local2)
19 local3 LOG_LOCAL3 local use 3 (local3)
20 local4 LOG_LOCAL4 local use 4 (local4)
21 local5 LOG_LOCAL5 local use 5 (local5)
22 local6 LOG_LOCAL6 local use 6 (local6)
23 local7 LOG_LOCAL7 local use 7 (local7)

3) Priority : 심각도를 의미

facility 심각도
none 저장된 facility제외
debug 1
info 2
notice 3
warning 4
error 5
crit 6
alert 7
emerge 8

4)설정 예시

*.emerg      shutdown - h now                    //모든 장치의 emerg발생시 Shutdown
kern.*         /dev/console                            //커널 관련 로그를 /dev/console에 남김
authpriv.*    /var/log/sercure                       //xinetd접속 로그를 /var/log/sercure 남김

*.info;mail.none     /var/log/message          //모든 facility에서 발생하는 info이상 심각도(2-8)의
                                                                     이벤트를 로깅하되 mail Facility에서 발생하는 로그는 로깅하지 않음
*.*;auth,authpriv.none,local0.none      -/var/log/syslog         
                                                                 //모든 로그(*.*)를 /var/log/syslog에 기록하지만, 세미콜론(;) 이후의 facility들인
                                                                   auth, authpriv, local0 은 제외(none)하라는 것임. 화일이름 앞의 
- 는 로그를
                                                                   파일에 바로 쓰지 말고 메모리에 로그를 가지고 있다가 디스크에 입출력 여유가
                                                                   있을 경우 쓰라는 의미임
                                                                (
http://shallowsky.com/blog/linux/rsyslog-conf-tutorial.html 의 Rules Section참조)

 

  • 파일 뿐 아니라 다른 곳으로도 로그를 보낼수 있음
    @IP, @[hostname] : 다른 서버로 로그 전달
    [사용자] : 지정한 사용자가 로그인 한 경우, 해당 사용자의 터미널에 표시
    * : 현재 로그인 되어 있는 모든 사용자의 터미널로 전달
    /dev/console, [터미널] : 지정한 터미널에 표시

1.Routing 확인 (목적지까지 최대 30홉을 지원하고 각 구간의 네트워크 상태를 확인)

  • traceroute (Linux, 33434~33439/UDP 사용) [-option] IP/Domain/Hostname
  • tracert (Windows, ICMP 사용) IP/Domain/Hostname

    →tcproute 등 다른 Utility 사용도 가능

   (예: tracert 127.0.0.1
          wildcard-tistory-fz0x1pwf.kgslb.com [xxx.xxx.222.33](으)로 가는 경로 추적:
          1     1 ms     1 ms     2 ms  xxx.xxx.219.1

          2      *           *           *         Request Time Out )

      → * : 패킷의 Trace 결과가 5초 이내에 도달하지 않으면 해당 왕복시간은 *로 표시

 

* traceroute Option

 -I(대문자 i) : traceroute의 옵션으로 UDP가 아닌 ICMP를 사용하여 라우팅 추적
 -n : 빠른 명령을 위한 DNS lookup 비활성
 -w seconds : 응답 패킷을 수신 받기 위한 시간(Default 5초)
 -q number : hop단 traceroute query수행 횟수(Default 3회)

* tracert Option

 -d : tracert의 옵션으로 주소를 호스트 이름으로 확인하지 않아서 빠른 결과 확인가능

 -h maximum_hops    대상 검색을 위한 최대 홉 수(Default 30홉)
 -j host-list       host-list에 따라 원본 라우팅을 완화(IPv4만 해당)
 -w timeout     각 응답의 대기 시간 제한(밀리초)
 -R                 왕복 경로를 추적(IPv6만 해당).
 -S srcaddr    사용할 원본 주소(IPv6만 해당).
 -4                 IPv4를 사용
 -6                 IPv6를 사용

 

** trace결과(*로 표시) 대응 방법

IPS(침입차단시스템), 방화벽 등의 접근통제에 의해 trace의 UDP 또는 ICMP패킷이 보안상의 이유로 차단되었거나
실제 해당 구간에 문제가 발생한 경우임

  - trace한 주소가 실제 존재유무 체크, 패킷이 멈춘 곳의 IP를 네트워크팀에 확인

  - trace 수행속도가 느리면 어느 지점에서 시간을 많이 잡아먹었는지 확인

 

 

2.Network Interface 확인(TCP/IP 프로토콜 진단)

  • netstat [-option]

   (예: netstat -ant      // all, port by number, tcp
         프로토콜, 로컬 주소, 외부 주소, 상태, 오프로드상태 등을 출력)

 

* Option

-a 모든 소켓 정보를 출력(모든 연결 및 수신 대기 포트를 표시)

-b 외부와 통신하는 실행파일([]안에표시)과 프로토콜, 내외부정보를 출력
     (각 연결 또는 수신 대기 포트 생성과 관련된 실행 파일을 표시)
      [관리자권한으로만 수행 가능, 출력시간이 오래 걸림]

-r 라우팅 정보를 출력

-i [interval] 네트워크 인터페이스에 대한 정보를 출력
   (Windows는 -i 옵션없이마지막에 interval 숫자만 주면됨)

-s 프로토콜(IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP 및 UDPv6)에 대한 통계 정보를 출력

-n 외부 네트워크 정보(IP, Port)를 숫자로 출력

-e 이더넷 통계를 표시(인터페이스 통계, -s 옵션과 함께 사용가능)

-o 각 연결의 소유자 프로세스 ID를 출력

-t TCP만 출력

-u UDP만 출력

 

**State 필드정보
   6.네트워크 > TCP Diagram 참조      (https://roby.tistory.com/category/6.%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC)

**상세활용 참조블로그

김선광의 IT블로그 :  https://blog.naver.com/sunkwang0307/222601632550

 

 

3. Ping (접속할 host가 정상 운영되고 있는지 확인, ICMP 사용)

  • ping [-option] IP/Domain/Hostname

    (예: ping 127.0.0.1 -t   //수동으로 멈출때까지 반복 수행, Default 4회)

 

* Option

-t : Ctrl+C로 중지 할 때까지 패킷 전송
  (예: ping 127.0.0.1 -t)
-i(interval) : Ping 주기 지정 옵션(Default 1초)
  (예: ping 127.0.0.1 -i 0.5  //0.5초 주기 패킷 송부)
-s : 전송 패킷 Size를 지정 (Windows : -l)
  (예: ping 127.0.0.1 -s 100 //100byte 크기 패킷 송부)

-w : 정한 시간동안 패킷 전송(Windows : 응답 대기시간-밀리초)
  (예: ping 127.0.0.1 -2 10    // 10초동안 패킷 전송)

-c(count) : 전송할 패킷 수 지정 (Windows : 없음)
  (예: ping 127.0.0.1 -c 10    // 패킷을 10번 전송)

-D : 결과 앞에 타임스탬프 출력 (Windows : 없음)
  (예: ping 127.0.0.1 -D)
-f(flood mode) : 빠른 속도로 패킷 전송하여 상태 확인 (Windows : 없음)
  (예: ping 127.0.0.1 -f)
-O : 전송한 패킷에 대한 응답 패킷을 출력, 어디서 오류 발생했는지 출력 (Windows : 없음)
  (예: ping 127.0.0.1 -O)

 

1. Amazon Web Services, Amazon WorkDocs,  Amazon API Gateway, Amazon WorkMail,  AWS Application Discovery Services, Amazon WorkSpaces,  Amazon AppStream, AWS Batch,  Auto Scaling, BOX,  AWS Artifact, ACM(AWS Certificate Manager),  Amazon Athena, AWS CloudFormation,  Aurora, AWS CloudHSM(Hardware Security Module)
2. Amazon Cognito, AWS CodeDeploy, AWS CloudTrail, AWS Data Pipeline, Amazon CloudWatch, AWS DMS, AWS CodeBuild, Amazon DynamoDB, Amazon CloudFront, AWS Device Farm, AWS CodeCommit, AWS Direct Connect, CodePipeline, AWS Directory Service, AWS Config, EBS(Elastic Block Store)
3. Amazon EC2 (Elastic Compute Cloud),  AWS Elastic Beanstalk, Amazon ECS (EC2 Container Service), AWS EMR (Elastic MapReduce), Amazon Elastic Transcoder, ENI (Elastic Network Interface), Amazon ECR,   EC2 Container Registry, Amazon ElasticCache,   Amazon EC2 Elastic GPUs,       Amazon EFS (Elastic File System), AWS EC2 – F1 인스턴스 타입 ELB(Elastic Load Balancing), Amazon EC2 System Manager
4. Elastic IP address (EIP), Amazon Inspector, Amazon ES, Amazon Kinesis, Amazon GameLift, AWS Lambda, Amazon Glacier, AWS Lambda@Edge, AWS Greengrass, Amazon Lex, Amazon Glue, Amazon Lightsail, IAM(Identity and Access Management), Amazon Machine Learning, AWS IoT, AWS Managed Services
5.Amazon Mobile Analytics, Amazon Rekognition, AWS Mobile Hub, Amazon Route 53, AWS OpsWorks, Reserved Instance (RI), Amazon Polly, Amazon S3 (Simple Storage Service), Amazon Pinpoint, AWS Service Catalog, Amazon QuickSight, Amazon SES(Simple Email Service), Amazon RDS (Relational Database Service), AWS SMS (Server Migration Service), Amazon Redshift, AWS Shield
6. AWS Snowball, AWS Storage Gateway, AWS Snowmobile, Amazon SWF (Simple Workflow Service), Amazon SQS (Simple Queue Service), Amazon Trusted Advisor, AWS Step Functions, VM Import / Export, Amazon SNS (Simple Notification Serivce), Amazon VPC (Virtual Private Cloud), Spot Instance, AWS WAF, AWS Organizations, AWS X-Ray

1.TCP 3way-handshaking

4계층의 대표적인 TCP는 신뢰성을 기반으로 설계된 프로토콜로서 서비스의 논리적연결(Session)을 담당하며 신뢰성 확보를 위해 3way-handshaking 방식으로 통신한다.

3way-handshaking 방식은 전송데이터의 유실을 방지하고, 정확한 정보전송을 보장하기위한 네트워크 구성방식이나 connection 구성에 따른 불필요한 데이터가 송수신 됨으로써 과도한 overhead가 발생한다.

※ Sync Flooding : TCP의 특성을 이용한 해킹기법

- 공격자가 다수의 패킷을 서버로 보내고 ACK는 보내지 않아서 연결은 종료되지 않고 서버의 리소스가 소비되어 정상적인 사용자가 연결을 시도할 때, 서버 접속이 불가능하게 된다.

Sync Flooding 공격 발생시 서버는 자신이 연결하고 있지 않은 출발지에서 유입되는 다양한 패킷을 처리하고 확인하는 과정에서 과부하를 야기함 

Sync Flooding 방어 방법 

- Syn Flooding 공격방어 및 완화를 위해서는 TCP프로토콕이 연결 지향성(Connection-Oriented)이라는 점을 이용하고

  Handshake과정에 위배된 TCP 패킷이 유입될 경우 비정상적인 트래픽으로 구분하여 차단하는 방법이 가장 효과적임

1)임계치 기반의 Syn Flooding 차단
방화벽의 IP당 Syn요청에 대한 PPS 임계치를 단계적으로 조정하여 Syn Flooding을 차단함

PPS 설정 예시

2)First Syn Drop(Spoofed) 설정에 의한 차단
Syn패킷을 보내는 클라이언트가 진짜 존재하는지를 파악하여 차단하는 방법으로 클라이언트로부터
전송된 첫번째 Syn을 Drop하여 재요청 패킷이 도착하는지를 확인하여 Spoofing 여부를 판단하고 차단함

 

3)Syn이외의 Flooding 공격 방어
Syn이외의 Flooding 공격을 방어하기 위해서는 다음과 같은 다양한 형태의 DDoS 방어 기법을 사용
먼저 정상적인 TCP세션 연결이후 정상적인 트랜잭션이 수해되는지에 대해 검증하여 만약 정상적인 트랜잭션이
일루어질 경우 서버로 전달해야 하고, 정상적인 트랜잭션 없이 TCP세션 연결만 수행할 경우에는 서버로 전달하지
않아야 서버에 부하 증가 현상을 막을 수 있음
또한 네트워크의 정상적인 환경에서 설정된 각 트래픽 유형별 임계치를 통하여 과도한 TCP세션 연결에 대해 차단

**TCP/IP Overhead 참고 링크 : http://tech.kakao.com/2016/04/21/closewait-timewait/

 

[TCP Diagram]

TCP Diagram

TCP 기반의 네트워크는 connection의 요청이나 종료를 대기하거나 서로간에 negociate 하기 위한 상태를 가지고 있다


2. TCP Diagram 상태 설명

상태 의미
LISTEN 서버 어플리케이션은 서비스를 위한 포트개설, 서버 TCP는 연결 요청을 기다리는 상태
*서버가 클라이언트의 접속요청 대기
SYN_SENT 연결 요청을 하고(SYN 세그먼트 전송), 서버 응답을 기다리는 클라이언트의 상태
*클라이언트 → 서버로 접속 요청
SYN_RCVD 클라이언트에게 SYN세그먼트를 받고, ACK/SYN 플래그가 설정된 응답 세그먼트를 보낸 후 클라이언트의 ACK 세그먼트를 기다리는 서버의 상태
*서버(클라이언트의 접속 요청을 받고)가 클라이언트에게 접속 요청 응답
ESTABLISHED 3 Way-Handshake과정이 완료되어 연결이 완료된 상태
*클라이언트와 서버가 서로 세션 확립 상태
FIN_WAIT_1 클라이언트의 어플리케이션이 회선 종료를 요청하고 FIN 세크먼트를 서버에 전송한 클라이언트의상태
*접속을 끊기 위해 소켓을 close하고 close 요청(close 발생 주체는 서버 또는 클라이언트)
CLOSE_WAIT FIN 세크먼트를 수신하고 이에 대한 ACK 세그먼트를 클라이언트에게 전송한 서버의 상태
*close 요청을 받고 응답을 보냄
FIN_WAIT_2 서버에게 전송한 FIN 세크먼트에 대한 ACK 세그먼트를 수신했고, 서버로부터 FIN 세그먼트가 전송되기를 기다리는 클라이언트의 상태
*close 요청에 대한 응답을 받고 최종 응답 대기
LAST_ACK 요청받은 회선 종료에 대해 클라이언트에게 FIN 세크먼트를 전송하고, 이에 대한 ACK 세그컨트를 기다리고 있는 서버의 상태
*소켓을 close하고 최종 close 응답
TIME_WAIT 회선이 종료되었지만, 분실되었을지 모르는 세그먼트를 위해 당분간 회선을 유지하는 상태(회선 종료를 요청한 클라이언트에서만 나타나는 상태)
*최종 close 응답을 받고 미처 처리되지 못한 데이터를 처리를 위해 일정시간 유지 상태
active open 능동적으로 세션 확립에 대한 요청을 하는 과정으로 보통 클라이언트에서 이루어짐
(예: 클라이언트가 포트를 개방하고 서버에 접속 요청을 하는 것)
passive open 수동적으로 세션 확립에 대한 요청을 받는 과정으로 보통 서버에서 이루어짐
(예: 서버가 포트를 개방하고 클라이언트의 접속 요청을 대기하는 것)
active close 능동적으로 세션 해제를 발생시키는 과정으로 서버 또는 클라이언트가 될 수 있다
(예: 클라이언트가 접속을 끊거나 서버가 접속을 끊는것)
passive open 수동적으로 세션 해제에 대한 요청을 받는 과정으로 마찬가지로 서버 또는 클라이언트가 될 수 있다

3. TCP 상태 특징
1) TCP 연결은 양방향이므로, 양 측에서 각각 다른 상태를 관리하게 됨
- 즉, 다른 경로를 통해 `TCP 연결 설정` 및 `TCP 연결 종료`에 갈 수 있음

2) 2가지 다른 TCP 연결 설정 경로
- (능동 개방) Closed -> Listen -> SYN-Received -> Establshed
. 자발적으로 SYN 세그먼트를 보내며 연결 설정하는 경우
- (수동 개방) Closed -> SYN-Sent -> Established
. 수동적으로 SYN 세그먼트를 수신하며 연결 설정하는 경우
  -> 주로, 서버 응용이 TCP에게 상시적 연결 수용 및 대기

3. 다른 연결 종료 경로
- (수동 종료) Eatablished -> Close-Wait -> Last-ACK -> Closed
. 상대로부터 FIN 세그먼트를 받고, 이에대해 응답하며 종료하는 경로
- (능동 종료) Eatablished -> FIN-Wait-1 -> FIN-Wait-2 -> Time-Wait -> Closed
또는, Eatablished -> FIN-Wait-1 -> Closing -> Time-Wait -> Closed
. 자발적으로 FIN 세그먼트를 보내고, 응답을 기다리며 종료하는 과정

 

4. 세그먼트(전송 계층에서의 데이터 전송 단위) 설명

명칭 의미
SYN(Synchronize) 연결 시작, 회선 개설 요청에 사용되는 세그먼트이다. TCP 에서는 접속 요청을 하는 주체가 SYN 세그먼트를 전송하고 요청을 받는 주체는 여기에 값을 추가해서 응답한다.
ACK(Acknowledgement) 요청에 대한 응답 세그먼트이다.
RST(Reset) 연결 리셋에 대한 세그먼트로 유효하지 않은 연결에 대한 시도를 했다거나 통신의 연결 및 종료를 정상적으로 할 수 없을때 사용된다.
FIN(Finish) 연결 해제, 회선 종결 요청에 사용되는 세그먼트이다.
MTU(Maximum Transmission Unit) MTU는 그림에는 나와있지 않지만 MSS의 설명이 필요하기 때문에 언급하게 되었다. MTU란 TCP/IP 네트워크 등과 같은 패킷 또는 프레임 기반의 네트워크에서 한번에 전송될 수 있는 최대 크기의 패킷 또는 프레임을 말한다. 단위는 Byte이며 MTU 값은 네트워크 인터페이스나 대역폭 등 네트워크 환경에 따라 달라질 수 있는데 일반적으로 흔히 쓰이는 이더넷의 경우 MTU 값은 1500을 사용하고, FDDI는 4000, X.25는 576, Gigabit는 9000정도를 사용한다.
MSS(Maximum Segment Size) MTU에서 헤더를 제외한 TCP상에서 전송 할 수 있는 사용자 데이터의 최대 크기에 해당하는 세그먼트이다. 위 그림에서는 처음 접속 요청시 1460바이트에 해당하는 MSS를 전송하고 있다. 이것은 이더넷과같은 환경에서 MTU를 1500으로 사용했을 때 여기에 IPv4 헤더의 20바이트와 TCP 헤더의 20바이트를 뺀 값이다. 그리고 응답시에는 1024바이트로 응답하는데 이것은 1024바이트의 크기의 단위로 데이터를 전송하겠다는것을 의미한다.

 

5. 비정상 종료 상황 예시

명칭 의미
CLOSE_WAIT - 어플리케이션에서 close()를 적절하게 처리해주지 못하면, TCP 포트는 CLOSE_WAIT상태로 계속 기다림
- CLOSE_WAIT상태가 statement에 많아지게 되면 Hang이 결려 더 이상 연결을 하지 못하는 경우가 발생한다 따라서 어플리케이션 개발 시 여러 상황에 따라 close() 처리를 잘 해줘야 함
FIN_WAIT_1 - 상대방 측에 커넥션 종료 요청을 했는데 ACK를 받지 못한 상태로 기다리고 있음
- 서버를 찾을 수 없는 것으로 네트워크 or 방화벽의 문제일 수 도있음
- FIN_WAIT_! 상태는 일정시간이 지나 Time Out이 되면 자동을 종료함
FIN_WAIT_2 - 클라이언트가 서버에 종료를 요청한후 서버에서 요청을 접수했다고 ACK를 받았지만, 서버에서 종료를 완료했다는 FIN을 받지 못하고 기다리고 있는 상태
- 이 상태는 양방 간 두번의 통신이 이루어졌기 때문에 네트워크 문제는 아닌 것으로 판단되며, 서버 측에서 CLOSE를 처리하지 못하는 경우일 수도 있음
- FIN_WAIT_2 역시 일정시간 후 Time Out이 되면 자동을 종료함

 

+ Recent posts