OSI 7 Layer reference
open [공개문서, 일반적으로 표준] -> 표준을 유도하려고 만들었다.
시스템 사이에서 연결하기 위해 7단계로 나눴다.
1. 개발이나 Troubleshooting이 용이하다.
2. 각 계층별로 사용될 용어가 정의가 되어 있기 때문에 표준으로 사용한다.
3. 호환성의 필요
L7 - L6 - L5 : 상위 계층으로 데이터를 생성하고 자연어에 가깝다. -> 하위 계층에서 조각화(fragmentation) 한 것을 재조립(reassembly)
L4 - L3 - L2 - L1 : 하위 계층으로 데이터를 전송(Incapsulation)하고 기계어에 가깝다. -> 조각화(fragmentation)
※ SDU : service data unit , 헤더를 뺀 본체의 데이터를 부르는 명칭 , 또는 payload라고 부르기도 한다.
※ PDU : protocol data unit , 헤더를 포함한 본체의 데이터를 부르는 명칭 ,
ex) 4계층의 PDU는 3계층의 SDU와 같다. -> 디캡슐레이션 과정에서 하위 계층에 헤더가 붙어서 전송되기 때문이다.
bit > frame > packet > segment > data
※ OSI 7 Layer 각 계층별 특징
L7 : 사용자에게 [ 정해진 규칙 = protocol 에 맞춰 ] 편리한 인터페이스를 제공하는 계층 , 일반 사용자들이 사용하기 편리하게 규칙을 정해놓은 계층
L6 : 압축[손실성 있는 것과 없는 것] , 포맷, 암호화를 담당하는 계층
- 압축 : 데이터를 합치는 압축이 있고, 데이터를 줄이는 압축이 있는데 여기서 쓰이는 압축은 데이터를 줄이는 개념으로 쓰인다. 알고리즘과 같은 수학적 기법이 사용되는 계층
- 포맷 : 한글 16bit -> base64로 encode -> ascii code [7bit] / url encode / CRC....
- 암호화
1) 수식 정의( 소인수 분해, 이산대수 문제) : 만든 사람은 쉽게 풀수 있지만 모르는 사람은 풀기 힘든 수식,
보통 암호화 길이가 200자리가 넘기 때문에 직접 암호를 짠 사람 외에 다른 사람이 접근 하려고 하면 굉장한 시간을 들여서 경우의 수를 구해야 한다.
2) 절차 - feistal 구조
ex) A = 65 라는 데이터가 있다고 가정 -> 어떤 복잡한 함수 식[ x + 1(암호를 넣을 때 사용할 키 : 암호화 키)] 넣어서 목적지 전송 (encryption) -> 목적지에서도 복잡한 함수식 [ x - 1(암호를 풀 때 사용할 키 : 복호화 키) ] 넣고 원래 데이터를 확인 (decryption)
-> 암호화 키 = 복호화 키 = 비밀키 , 대칭키 알고리즘 ex) DES, 3DES, AES // 대한민국은 SEED, ARIA 사용
-> 암호화 키 != 복호화 키 , 비대칭키 알고리즘
* 암호화 키 = public key = 공개키
* 복호화 키 = private key = 사설키 , 개인키
* 세션키 = 데이터를 나눠서 서로 맞는 데이터 있는 확인 시에 쓰이는 키
ex) DH (diffie hellman) 방식 => 세션키 생성에 사용 , RSA 방식 [ 암호화키와 복호화키의 역할 변경이 가능 (암호화 + 인증)] -> 공인 인증서 방식에서 사용한다.
※ block cipher : 암호를 block 단위로
※ stream cipher : 1bit 단위로 암호화 -> 애니그마가 대표적 -> RC4 , TKIP
암호화 강도가 낮다. 대신 연산이 빠르고 연산 리소스 소모가 적다.
최근에는 이 방식와 OTP를 함께 사용하여 암호화 강도를 보완해준다.
※ 해시 : 무결성 체크 , 압축 , 데이터 -----> hash 함수 [md5, sha -1] --> hash code [128bit / 160bit]
해시 계산기
오늘 하루도 화이팅! encrypt => 96df574456355117be0b7c5c1387c287 [128bit] 해시 값
-> 해시는 단방향이라 나온 해시 값을 다시 집어넣어도 내가 원하는 데이터가 저장되어 있지 않다. (역함수 x)
오늘 하루만 화이팅 encrypt => 751f8651eb0c3d02622d9fb652808472 [128bit] 해시 값 비교
L5 : 세션 계층 , 통신(대화)의 내용
stateless(서버가 클라이언트의 세션 상태 및 세션 정보를 저장하지 않는 네트워크 프로토콜)
-> stateful(세션이 종료될 때까지, 클라이언트의 세션 정보를 저장하는 네트워크 프로토콜입니다.)
cookie, http 헤더 (referer 헤더), 보안을 위해 https 등장 -> 그렇지만 SNI이라는 곳에 적혀 있기는 하다.
L4 : 포트 주소 [ICANN] = 16bit = 2^16 = 0 ~ 65535까지 정의
0~255 : 공공의 목적으로 사용되는 포트 번호
256 ~ 1023 : 상용 포트 [ssl 443 넷스케이프가 만든 웹보안 + http = https ==> 표준화 시킨 것은 TLS]
================== 0 ~ 1023 port : well known port -> 강력한 관리 ======================
1024 ~ 49151 : 등록 포트 , 충돌 방지를 위해서 ICANN에 미리 등록하고 사용한다.
49152 ~ 65535 : 임의 포트 , 동적포트
================== random port ==================================================
※ TCP (Transmission Control Protocol)
- connection oriented protocol (연결 지향 프로토콜)
- 사전에 미리 통신 채널을 생성한다. 통신 하기 전에 연결 설정, 연결 관리, 연결 해지의 과정을 거친다.
- 신뢰성 있는 프로토콜로 장거리나 대용량에 적합하다.
- flow control, error control , congestion control 기능
- 확인 응답을 한다 [ 수신완료 : ack , 수신 안됨 : nak] ,
- 순서 번호의 개념이 있다. 조각화 한 후 재조립 과정을 거친다.
- TCP 헤더는 기본적으로 20byte인데 옵션이 최대 40byte까지 붙는다. 이때 20 byte + 40 byte = MPTCP
-> MPTCP + DATA [ MSS: Maximum Segment Size ] = L4 PDU
- http [ tcp 80 ] , telnet [ tcp 23 ] , ssh [ tcp 22 ] , ftp [ tcp 20 - 21] ..
※ UDP (User Datagram Protocol)
- overheader가 없다.
- 신뢰성 없는 프로토콜이다. -> 상위 계층에서 신뢰성을 체크 (이 프로토콜 자체는 하지 않는다.) , best effort
- 통신 환경이 열악한 곳이나 빈번한 통신이 사용되는 곳(시스템 관리 = snmp, dns ...), 실시간 데이터(음성, 영상)를 보내는 곳[ RTP : Real Time Protocol 통해서 보낸다. 12byte의 길이를 가진다. ] 에서 사용된다.
-> port 16384 ~ 32767 사용
ex) 여보세요 라고 했는데 TCP를 쓴다면 여 (확인) 보 (확인) 세 (확인) .. 이런 식으로 느려질 뿐만 아니라 데이터가 하나 잘못 보내지면 여 세 요 .. 이런 식으로 데이터가 오는 말도 안되는 상황이 올 수 있기 때문에 무조건 UDP 를 사용한다.
- 확인 응답을 하지 않는다.
- 순서 번호의 개념 없이 보낸다.
- TCP와 달리 연결 설정, 연결유지, 연결 해지 절차가 없다. = 비연결지향
- flow control, error control , congestion control 기능도 없다.
- UDP 헤더 (8byte) + data (datagram)
- dns [ udp , tcp 둘다 사용 , 가장 가까운 서버에 빈번한 전송이 발생할 때는 udp ]
- dns [root DNS - TLD - local DNS ] A - M 전 세계 13개 , 대한민국의 3개
'Network > 이론' 카테고리의 다른 글
| 네트워크 이론 - 5 (0) | 2022.09.06 |
|---|---|
| 네트워크 이론 - 4 (0) | 2022.09.05 |
| 네트워크 이론 -2 (0) | 2022.09.02 |
| 네트워크 이론 - 1 (0) | 2022.09.02 |
| OSI 7 Layer 모델 & TCP/IP 모델 (0) | 2022.08.27 |
