보다 나은 내일, 다이어리

22. HIPO

Hierarchy Input Process Output

시스템의 분석, 설계, 문서화할 때 사용하는 기법.

HIPO Chart: 기능을 여러개의 고유 모듈들로 분할, 이들 간 인터페이스를 계층구조로 표현한 것

- 종류

가시적 도표(도식목차): 기능 계층 구조도

총체적 도표: 전반적 정보 제공

세부적 도표: 총체적 도표를 구성하는 세부요소

23. UML

Unified Modeling Language

시스템 분석, 설계, 개발 등 개발 과정에서 개발자와 고객 또는 개발자 간의 의사소통이 원활하게 이루어지도록 표준화한 객체지향형 모델링 언어

Rumbaugh, Booch, Jacobson 등의 객체지향 방법론의 장점을 통합

럼바우: 객체, 동적, 기능 모델로 나눠져

Booch: 미시적, 거시적 개발 프로세스 모두 사용, 클래스와 객체들 분석/식별, 클래스의 속성과 연산을 정의

Jacobson: 유스케이스 강조

6개의 구조 다이어그램(정적) + 7개의 행위 다이어그램(동적)

구성요소: 사물(Things), 관계(Relations), 다이어그램(Diagram)

24. 관계(Relations)

1. 연관 관계(Association): 2개 이상의 사물이 서로 관련
2. 집합 관계(Aggregation): 하나의 사물이 다른 사물에 포함 관계
3. 포함 관계(Composition): 집합 관계의 특수 형태, 포함하는 사물의 변화가 포함되는 사물에 영향 줌
4. 일반화 관계(Generalization): 하나의 사물이 다른 사물에 비래 더 일반적인지 구체적인지 표현
5. 의존 관계(Dependency): 한 클래스가 다른 클래스를 연산 매개변수로 사용하는 등 짧은 시간동안만 관계
6. 실체화 관계(Realization): 사물이 기능으로 서로를 그룹화할 수 있는 관계

25. 다이어그램(Diagram)

구조적 다이어그램(Structural) -정적- 6개

1. 클래스 (Class): 클래스 간 속성과 관계 표현
2. 객체 (Object): 클래스에 속한 객체인 인스턴스 간 특정 시점의 관계, 럼바우의 객체모델링에 활용됨
3. 컴포넌트 (Component): 실제 구현 모듈인 컴포넌트 간 관계나 인터페이스 표현
4. 배치 (Deployment): 결과물, 프로세스, 컴포넌트 등 물리적 요소들 위치 표현
5. 복합체 구조 (Composite Structure): 복합 구조 갖는 경우 그 내부 구조 표현
6. 패키지 (Package): 유스케이스나 클래스 등 모델 요소들을 그룹화한 패키지들 관계 표현

행위적 다이어그램(Behavioral) -동적- 7개

1. 유스케이스 (Usecase): 사용자(User)와 사용 사례(Use case)로 구성됨, 요구를 분석하는 것-> 기능 모델링에 활용됨
2. 순차 (Sequence): 상호작용하는 시스템이나 객체들이 주고받는 메시지 표현
3. 커뮤니케이션 (Communication): 순차 다이어그램의 메시지뿐만 아니라 객체들 간 연관까지 표현
4. 상태 (State): 객체가 자신이 속한 클래스의 상태 변화나 상호작용에 따른 상태 변화 표현,럼바우의 동적 모델링에 활용됨
5. 활동 (Activity): 객체의 처리 로직이나 조건의 처리흐름을 순서에 따라 표현
6. 상호작용 개요 (Interaction Overview): 상호작용 다이어그램 간 제어흐름 표현
7. 타이밍 (Timing): 객체 상태 변화와 시간 제약을 명시적으로 표현

26. 스테레오 타입(Stereotype)

UML에서 표현하는 기본 기능 외 추가 기능 표현

길러멧(Guilemet)이라고 부르는 겹화살괄호(<< >>)사이에 형태 기술

• <<include>>: 연결된 다른 UML 요소에 대해 포함 관계에 있는 경우
• <<extend>>: 연결된 다른 UML 요소에 대해 확장 관계에 있는 경우
• <<interface>>: 인터페이스 정의
• <<exception>>: 예외 정의
• <<constructor>>: 생성자 역할 정의

27. 유스케이스 다이어그램 (Use Case Diagram)

사용자와 다른 외부 시스템들이, 개발될 시스템을 이용해 수행할 수 있는 기능을

사용자 관점에서 표현한 것

구성요소

• 시스템/시스템 범위: 외부 시스템과 구분하기 위해 시스템 내부 유스케이스를 사각형으로 묶어 범위 표현
• 액터: 시스템과 상호작용하는 모든 외부 요소
• 유스케이스: 사용자 관점에서 시스템이 제공하는 서비스나 기능
• 관계: 액터와 유스케이스, 유스케이스 간 관계-> 연관관계, (포함관계), 확장관계, 일반화관계를 표현할 수 있음

28. 클래스 다이어그램

구성요소

• 클래스: 3개의 구획(Compartment)로 나눠 표기, 이름+속성+오퍼레이션(=동작,연산)을 표기
• 제약조건: 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면
• 관계: 클래스 간 관계 -> 연관관계, (집합관계, 포함관계), 의존관계, 일반화관계가 있음

29. 순차 다이어그램

구성요소

• 액터: 외부 요소 = 사람이나 외부 시스템
• 객체: 메시지 주고받는 주체
• 생명선 (Lifeline): 객체가 메모리에 존재하는 시간
• 실행 상자 (Active Box): 객체가 메시지를 주고받으며 구동되고 있음을 표현
• 메시지: 상호작용을 위해 주고받는 메시지

13. DBMS

사용자와 db 사이에 정보를 생성해주고 db를 구성,접근방법,유지보수,관리하는 소프트웨어

database management system

기존 db의 종속성과 중복성 문제를 해결

여러 응용 프로그램이 db로 접근 쉽게함 = 모든 응용 프로그램이 db를 공용하게 관리

종류? oracle, sqlite, db2, mongodb, redis, sql server...

고려사항? 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

14. 웹 어플리케이션 서버 (WAS)

정적 콘텐츠를 처리하는 웹서버와 달리, 사용자의 요구에 따른 동적 콘텐츠 처리 위한 서버.

주로 db 서버와 연동

데이터 접근, 세션 관리, 트렌젝션 관리 등을 위한 라이브러리 제공

종류? tomcat, jetty, resin, jeus, GlassFish

15. 요구사항 유형

기능/비기능 요구사항

16. 요구사항 개발 프로세스

도출->분석->명세->확인

Elicitation->Analysis->Specification->Validation

17. 요구사항 명세 기법

정형/비정형

비정형 명세 기법?

자연어 기반. 이해 용이. 일관성 떨어지고 해석 달라질 수 있음.

상태, 기능, 객체 중심!

ER modeling, State Chart, 등

18. 요구사항 분석의 개요

DFD, 자료사전, UML, 소단위 명세서, 개체관계도, 상태 전이도, 제어 명세서 등의 도구 이용

* UML(Unified Modeling Language) : 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하도록 한 객체지향 모델링 언어

19. 자료 흐름도(DFD)

Data Flow Diagram

요구사항 분석 과정 중 자료의 흐름과 변환과정, 기능을 도형 중심으로 기술

=버블 차트

네 가지 기호

프로세스(Process): 자료를 변환시키는 처리 과정, 변환, 버블

자료 흐름(Data Flow): 자료의 연관관계나 이동 .화살표

자료 저장소(Data Store): 데이터베이스나 파일 등 저장소,

단말(Terminator): 교신하는 외부 개체

20. 자료사전(DD)

Data Dictionary

자료흐름도의 자료를 더 상세히 기술 위함.

=데이터의 데이터 또는 메타데이터

08-06 다운 캐스팅과 instanceof

앞서 상속 관계를 가지는 구조에서 다형성을 활용하면 프로그램의 확장성이 높아진다는 것을 배웠다.

Animal ani = new Human()

상위 클래스로 묵시적으로 형 변환이 일어나는 것인데, 이 경우엔 Animal 클래스에서 선언한 메서드와 멤버 변수만 사용할 수 있다. 즉, Human 클래스에 더 많은 메서드와 멤버변수가 구현되어 있어도 사용할 수가 없는 것이다.

=> 다운캐스팅 ? 상위 클래스에서 형 변환되었던 하위클래스를 다시 원래 인스턴스의자료형으로 형변환하는 것 

(=downcating)

instanceof 예약어 ?

다운캐스팅 하기 전에 원래 인스턴스의 자료형을 확인해야 실행 오류를 막을 수 있다.

Animal hAnimal = new Human()

if(hAnimal instanceof Human) { 
	Human jm = (Human)hAnimal;
}

hAnimal의 원래 인스턴스형이 Human 클래스 자료형인가를 확인해줌.

instanceof의 반환값이 true면 다운 캐스팅을 함. 하위 클래스로 형변환을 할 때는 명시적으로 자료형을 작성해줘야 함.

"Do IT! 자바 프로그래밍 입문" 책을 읽고 요약하는 글입니다.

p.273~279

08-04 다형성

묵시적 클래스 형 변환과 가상 메서드를 사용한 객체지향의 주요 특징

= 하나의 코드가 여러 자료형으로 구현되어 실행되는 것

class Animal{ public void move() { "동물" 출력 }  }

class Tiger extends Animal { public void move() { "호랑이" 출력 } }

public class Test { .. public void moveAnimal(Animal animal) { animal.move() } }

가상 메서드 원리에 따라 호출되는 메서드는 자료형의 클래스의 메서드가 아니라 실제 인스턴스의 메서드다.

-> 어떤 매개변수가 넘어오더라도 자료형은 모두 Animal형으로 변환하지만, animal.move()는 실제 인스턴스에 따라 출력이 달라진다.

다형성의 장점? 

1) 프로그램의 확장성

2) 유지보수성

: 각 자료형에 따라 다르게 구현한다면 코드는 복잡해짐, 상위에서 공통 메서드 구현하고 하위에서 추가요소를 덧붙여 구현하면 각 클래스의 여러가지 구현도 할 수 있고(=확장성) 유지보수도 하기 쉬워짐

만약 재정의한 메서드가 가상 메서드 방식에 의해 자동으로 호출되지 않는다면 if-else if 문을 사용해서 따로 구현해야 할 것이다. 게다가 새로운 조건이 필요한 경우에는 또 다른 조건으로 구현해야 하기 때문에 코드의 유지보수가 어려워질 수 있따.

상속은 언제 사용할까?

IS-A (is a relationship; inheritance) : 일반적인 개념과 구체적인 개념

즉 일반 클래스를 점차 구체화하는(=확장되는) 상황에서 상속을 사용하는 것이다.

이질적인 클래스 간에는 상속을 사용하지 않는 것이 좋다

어떤 경우에 상속을 사용하지 말아야 할까?

HAS-A (has a relationship; association) : 한 클래스가 다른 클래스를 소유한 관계

예) Subject는 Student에 포함되는 것이기 때문에 상속을 사용해선 안됨

class Student { Subject majorSubject; }

알고가자!)  상속을 재사용의 개념으로 이해해선 안된다!

재사용할 수 있는 코드가 있다고 해서 무조건 상속을 하면 클래스 간의 결합도가 높아져서 오히려 상위 클래스의 변화가 하위 클래스에 미치는 영향이 커지게 된다. 결합도는 낮추고 응집도는 높이는 방향으로 소프트웨어는 설계되어야 함!

알고가자!)  여러 클래스를 한번에 상속받을 수는 없다. extends 뒤에는 상위 클래스 '하나만' 가능하다.

"Do IT! 자바 프로그래밍 입문" 책을 읽고 요약하는 글입니다.

p.259~272

08-01 상속이란?

B클래스가 A클래스를 상속받으면 B 클래스는 A 클래스의 멤버 변수와 메서드 사용 가능

-> 그 기반이 되는 기술이 '상속'

A 클래스: 부모, 상위 클래스

B클래스 : 자식, 하위 클래스

class B extends A { }

Customer 클래스와 VIPCustomer 클래스를 구현해본다고 하자.

VIPCustomer에게는 일반 고객에게 제공하는 혜택을 기본으로 하고 추가 속성과 메서드를 추가하면 됨.

public class VIPCustomer extends Customer {  }

Customer 클래스에서 사용한 변수인 customerGrade가 private으로 선언되어 있다면 protected로 바꾸자.

상위클래스에서 작성한 변수나 메서드 중 외부 클래스에서 사용할 순 없지만 항위 클래스에선 사용할 수 있도록 지정하는 예약어가 바로 protected ~!

그리고 get(), set() 메서드를 추가하자.

-> private 변수처럼 protected 변수도 외부 클래스에서 값을 가져올 수도, 지정할 수도 있게 된다.

08-02. 상속에서 클래스 생성과 형 변환

하위 클래스가 생성될 땐 상위 클래스의 생성자가 !반드시! 먼저 호출됨.

그리고 상위 클래스 생성자가 호출될 때 상위 클래스의 멤버변수가 힙 메모리에 생성되는 것임.

알고 가자!) 상위 클래스의 private 변수도 생성은 되지만 단지 하위 클래스에서 접근을 못하는 것일 뿐이다!

하위 클래스의 생성자에서 super()를 자동으로 호출하기 때문에 상위 클래스의 디폴트 생성자가 호출되는 것이다.

알고 가자!) super()는 컴파일러가 자동으로 추가하는 코드.

super로 상위클래스의 멤버변수나 메서드를 참조할 수도 있다.

super.showCustomerInfo()

상위클래스로 묵시적 형변환

Customer vc = new VIPCustomer()

VIPCustomer 클래스로 인스턴스를 생성할 때 이 인스턴스의 자료형을 Customer형으로 클래스형 변환하여 선언할 수 있음 = 업캐스팅(upcasting)

하지만, 클래스의 자료형이 Customer로 한정되어졌기 때문에 VIPCusotmer 클래스의 멤버변수와 메서드는 사용 불가능해짐.

만약 다시 사용하고 싶다면 VIPCustomer로 다운캐스팅(downcasting)하면 됨

알고가자!) 모든 하위 클래스는 상위 클래스 자료형으로 형 변환할 수 있지만, 그 역은 성립 불가

08-03. 메서드 오버라이딩

만약 '일반 고객은 정가를 그대로 지불하지만 VIP 고객은 10%할인은 받을 수 있다.' 는 가정이 생긴다면,

VIPCustomer에서 Customer 클래스의 calcPrice() 메서드를 그대로 사용할 수 없게 된다.

메서드 오버라이딩 : 상위 클래스에서 정의한 메서드가 하위 클래스에서 구현할 내용과 맞지 않을 경우 메서드를 재정의하는 것

알고가자!) 오버라이딩하려면 반환형, 메서드 이름, 매개변수 개수, 매개변수 자료형이 같아야 함

@Override

public int calcPrice(int price) { ... return price - (int)(price * 0.1)  }

 애노테이션 ? 컴파일러에게 특정한 정보를 제공해 주는 역할을 함, 만약 메서드의 선언부가 다르다면 컴파일 오류가 발생하여 개발자의 실수를 막아줌

예) @Override @FuntionalInterface @Deprecated @SuppressWarnings

가상 메서드 : 상속에서 상위 클래스와 하위 클래스에 같은 이름의 메서드가 존재할 때 호출되는 메서드는 인스턴스에 따라 결정됨.

선언한 클래스형 (x) 생성된 인스턴스 (o) 메서드를 호출

알고가자!) 인스턴스가 생성될 때마다 변수는 생성되지만, 메서드는 실행해야 할 명령 집합이므로 여러개 생성되지 않는다. 

일반적으로 메서드를 호출하면 '메서드 영역의 주소를 참조'하여 명령이 실행되는 것이다. 즉, 인스턴스가 달라도 동일한 메서드가 호출된다.

하지만 가상 메서드는 '가상 메서드 테이블'을 만든 후, 각 메서드 이름과 실제 메모리 주소가 짝을 이루고 있다가 테이블의 주소 값을 찾아서 해당 메서드의 명령을 호출하는 원리이다.

재정의된 메서드는 실제 인스턴스에 해당하는 메서드가 호출되고,

재정의되지 않은 메서드는 메서드 주소가 같으며 상위 클래스의 메서드가 호출된다.

// VIPCustomer 인스턴스를 Customer 형으로 변환
Customer vc = new VIPCustomer(10030, "나몰라", 2000)

=> 원래 Customer 형 메서드가 호출되는 것이 맞지만, 가상 메서드 방식에 의해 VIPCustomer 메서드가 호출된다!!

"Do IT! 자바 프로그래밍 입문" 책을 읽고 요약하는 글입니다.

p.232~258

그룹 프로젝트를 오랜만에 실행해 봤는데 `https://countryflagsapi.com/png/brazil` 을 불러오는 중에 에러가 발생했다. 

나라의 국기 사진을 api로 불러올 수 있는 사이트이다. 

아마도 cors 오류라고 생각이 들었지만 혹시 다른 api로는 될까 싶어서 이번엔 비슷한 사이트인 이곳에서 해보려고 했지만 여기는 나라코드로 분류하기 때문에 내 프로젝트에서 사용하려면 복잡해질 것 같아서 지금 상황에서 해결해야 했다.

CORS?

Cross Origin Resource Sharing, 교차 출처 리소스 공유

http 헤더 기반 메커니즘으로 한 출처에서 실행 중인 웹 어플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다. CORS 에러는 브라우저가 내뿜는 것이다. 

(보안 상의 이유로, 브라우저는 교차 출처 http 요청을 제한한다. 다른 출처의 리소스를 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해야 한다.)

참고: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Origin

Origin은 프로토콜(http, https,,), 호스트 이름(www와 같이 기기끼리의 통신 시 각 기기가 서로를 식별하도록 할당한 이름) 및 포트의 조합이다.

같은 origin이라면 same-origin(동일 출처), 다른 origin이라면 cross-origin(교차 출처)이다.

예를 들어 URL이 https://www.example.com:443/foo 인 경우 origin은 https://www.example.com:443 이고 same-origin이고 포트가 생략되어도 상관 없다.

cross-origin은 origin이 정확히 맞아떨어져야 하며 그 외는 모두 cross-origin이다.

• 도메인이 다르거나
• 하위 도메인이 다르거나
• 다른 프로토콜이거나
• 다른 포트 번호이거나

SOP와 CORS의 관계

SOP는 동일 출처 정책이고, CORS는 교차 출처 자원 공유다. 

SOP는 다른 origin으로 요청을 보낼 수 없도록 금지하는 브라우저의 기본적인 보안 정책이다. 즉, 동일한 origin으로만 요청을 보낼 수 있도록 하는 것이다. 그러나 몇가지 예외 사항에서는 다른 origin으로 요청을 보내야 하는데 그 때 지켜야 하는 정책이 CORS인 것이다. 원래대로라면 SOP에 의해 막히게 될 요청을 풀어주는 정책이라고 할 수 있다.

여기서 몇 가지 예외 사항이란,

1. <script>태그로 javacript를 실행하는 경우,

2. 이미지를 렌더링하는 경우,

3. <link>태그로 스타일 시트 파일을 불러오는 경우,

4. HTML 문서를 화면에 보여주는 경우를 말한다. 

출처: https://www.rfc-editor.org/rfc/rfc6454#section-3.4.2

CORS 해결하기

CORS의 기본적인 동작원리는 단순하다. 브라우저는 다른 origin으로 요청을 보낼 때 origin 헤더에 자신의 origin을 설정하고, 서버로부터 응답을 받으면 Access-Control-Allow-Origin 헤더에 설정된 origin 목록에 요청의 origin 헤더 값이 포함되는 지 검사하는 것 뿐이다. 즉, 응답의Access-Control-Allow-Origin 헤더에 허용되는 origin 또는 *을 설정해주면 된다.

하지만 이 방법은 server에서 해결하는 방법이고 만약 server를 수정할 수 없거나 외부 api를 사용하는 경우엔 클라이언트에서 처리를 해주어야 하는데, 그 방법 중 하나가 프록시 서버를 이용하는 것이었다.

프록시 서버란 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 서버를 가리킨다. 즉 프론트에서 프록시 서버를 거쳐서 출처를 response와 같게 수정하고, server에 접근하도록 하는 것이다. (나중에 강의를 통해서 더 이해하고 싶다.)

React에서 proxy server를 구축하는 방법으로 http-proxy-middleware를 사용했다. 하지만 배포할 땐 적용이 안 되고, 개발할 때만 적용이 된다..

먼저 http-proxy-middleware를 설치한다.

 yarn add --dev http-proxy-middleware

setupProxy.js를 src 밑에 세팅한다.

const { createProxyMiddleware } = require("http-proxy-middleware");

module.exports = function (app) {
  app.use(
    createProxyMiddleware("/png", {
      target: "https://countryflagsapi.com",
      changeOrigin: true,
    }),
  );
};

• createProxyMiddleware("/png", {})의 "/png"는 "/png"로 시작하는 endpoint를 가진 api와 모두 매칭시킨다
• target에는 url의 endpoint를 제외한 출처만 명시한다. https://countryflagsapi.com/png/brazil의 경우, endpoint를 제외한 /png를 제외한 https://countryflagsapi.com로 명시한다.
• changeOrigin는 호스트 헤더의 출처를 대상 URL로 변경 하는지 여부입니다. CORS 처리를 위해 출처를 수정해주어야 합니다. 기본값은 false이다.

api 호출하는 파일

url의 endpoint인 "/png/~"로 호출합니다. proxt를 세팅하면 서버를 재시작해준다.

<ListItemAvatar>
  <Avatar
    alt="국기"
    src={`/png/${data?.country}`}
  />
</ListItemAvatar>

결과

나라 국기 이미지가 잘 출력됨을 알 수 있다.

항상 cors 에러,,cors 에러,, 많이 들어보았지만 이렇게 맞닥뜨린 건 처음같다. 옛날에 공부해 본 적은 있는데 이렇게 실전에서 해결..?하고 나니까 좀 더 이해가 된 느낌이다. 나중에 다시 만나도 반갑게 해결할 수 있겠지?

참고 사이트:

https://www.datoybi.com/http-proxy-middleware/

https://xiubindev.tistory.com/115

https://it-eldorado.tistory.com/163

https://evan-moon.github.io/2020/05/21/about-cors/

Router는 L3 Switch지만 Host라고도 할 수 있음 (IP도 다 부여, 컴퓨터라고도 할 수 있음)

라우터에 NIC가 여러개 있을 수 있다.

패킷이라는 것이 처리될 때, 라우터 같은 Inline 장치가 어떻게 처리될까?

라우터 내부에서 외부로 통신을 할 때 NIC#1에서 출발하여 IP→TCP→Process→TCP/IP →NIC#2 의 경로를 탈 수 있지만 User모드, Kernel모드, HW를 나누는 경계선을 건널 때마다 waiting 시간이나 CPU를 사용하기 때문에 전산 비용이 비싸진다.

그러므로 NIC#1 ⇒ NIC#2 로 한번에 가도록 하는 HW기반 통신을 하면 ‘가속했다’고 얘기하면서 굉장히 빨라진다.

그런데 NIC#3이 또 있을 수도 있다.

따라서 NIC#1에서 출발하여(=네트워크로 프레임 단위 데이터가 들어와서 패킷 단위로 잘라지든 해서 데이터를 Read했다) IP단에서 처리한 뒤 write를 해야 할 때, NIC#2로 보낼지 NIC#3로 보낼지 인터페이스를 선택을 해야 함

그런데 만약 Read를 했는데 write를 안한다면? 패킷이 필터링되어서 drop이 됨

패킷의 정보를 보고 어디로 보낼지 결정해야 하는데 L3 Switch니까 IP주소를 보고 할 것이다. 그런데 두 개의 NIC 중 적절한 게 없다면 못보내서 Drop되는 경우도 있다.

라우터가 IP단에서 단지처리만 한다면 L3 Switch, Router만이지만, 패킷을 보안적인 측면도 생각해서 처리하면 패킷 단위의 필터링 방화벽이 된다. 필터링을 거쳐서 Bypass 또는 Drop도 하게 되는 것이다.

*Inline 구성이란??

• 인라인 구성은 모든 트래픽이 해당 보안 장비를 물리적으로 거쳐야만 목적지로 전송될 수 있도록 네트워크를 구성한 것을 말한다.
• 상/하단 장비와 동일 대역대에 위치하며 기능을 수행하는 포트에 IP 설정이 필요없는 장비

패킷 단위의 감시대상이 장비를 통과하는 모든 트래픽

• Inbound 트래픽 : 방향성이 내부를 향함. 클 → 서버
• Outbound 트래픽 : 방향성이 외부를 향함. 서버 → 클

Bypass를 하든지 Drop을 하든지 !

출처: (널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

https://run-it.tistory.com/40

• socket + stream
• TCP + Segment (MSS)
• IP + packet (MTU)
• NIC + Frame
• IP와 Driver 사이에 있는 공간
  • Filter → Filter에서 넘어가면 ByPass, 걸러지면 Drop
  • 필터할 필요가 없다면 Sensor → 항상 ByPass면서 감시하면서 수집, 캡쳐만 함 (예. Npcap 드라이버)
  • Wireshark가 이 캡쳐들을 디코딩함 즉, Analyzer
  • 그런데 만약 카톡을 수집한다면 도감청에 잡혀갑니다. 그런 의미에서 Sniffer라고도 함
  • 그러므로 적법한 목적 상의 수집인지가 중요합니다. 윤리의식 중요!!
• 트래픽이 호스트에서 네트워크쪽으로 나가는 것이 Outbond, 그 반대가 Inbound

출처(널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

Header + Payload

• Header에서 TCP인지 IP인지 특징 : 20 byte
• Payload
  • MSS (Maximum Segment Size) : 1460 byte
  • MTU (Maximum Transmission Unit) : 1500 byte

• Data : 2^{16} byte (64 KB) 까지 → Total Length가 16 bit 이므로 총 2^{16}가지의 수를 표현할 수 있음

(1KB = 1024Byte)

• IHL (Internet Header Length) : 주로 5 bit
• TOS (Type Of Service) : 대역폭 품질 관리 시 기재
• Identification, Flags, Fragment offset : 단편화와 관련됨
  • MTU가 1400일 때 1500 크기를 보내야 할 때 단편화해서 보내야 하는데
  • 보낼 때 순서를 알아야 하므로 ID가 필요
• TTL (Time To Live) : 패킷이 인터넷에 너무 오래 있어서 버려져야 하는지 여부 알려줌
  • 인터넷에선 라우터라는 거대한 집합체가 패킷을 유통한다. 그 과정에서 문제가 생길 수 있으므로 R→R으로 이동할 때마다 TTL을 1씩 감소시킨다. 그러면 TTL이 언젠가 0이 될 텐데 그때 그 라우터가 패킷을 버린다.
• Protocol : 상위 계층 프로토콜을 가리킴, L4
• Header Checksum : 오류여부 확인

잘 정리된 사이트: https://mindnet.tistory.com/entry/네트워크-쉽게-이해하기-18편-IP-Header-IP헤더-구조

출처(널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

L2에서는 Mac 주소 (48bit)

네트워크는 한 마디로 switch의 집합체다..!

• NIC
• L2 Access switch ****: PC와 같은 endpoint들이 처음 만나게 되는 switch (방 하나)
• L2 Distribution switch : switch를 위한 switch (건물의 층 하나)
• Router : 전체 PC들의 gateway 역할 (건물 하나)
• Internet
• Uplink : 상위 계층 스위치로 연결됐다는 의미 (L2 Access → L2 Distribution)
• Link-up: 케이블 연결이 딱 됐다는 의미
• Link-down : 연결이 해제됐다는 의미

출처(널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy