쌩로그

외워서 끝내는 네트워크 핵심이론 - 기초 본문

CS/네트워크

외워서 끝내는 네트워크 핵심이론 - 기초

.쌩수. 2023. 11. 6. 23:57
반응형

목차

  1. 포스팅 개요
  2. 본론
        2-1. Layer와 Layered 구조
        2-2. 네트워크와 네트워킹 그리고 개념
        2-3. User mode와 Kernel mode
        2-4. OSI 7 layer와 식별자
        2-5. Host는 이렇게 외우자
        2-6. 스위치가 하는 일과 비용
        2-7. NIC, L2 Frame, LAN 카드 그리고 MAC 주소
        2-8. 스위치에 대해서
        2-9. LAN과 WAN의 경계 그리고 Broadcast
        2-10. IPv4 주소와 기본 구조
        2-11. L3 IP Packet으로 외워라
        2-12. Encapsulation과 Decapsulation
        2-13. 패킷의 생성과 전달
        2-14. 계층별 데이터 단위
        2-15. [※중요] 이해하면 인생이 바뀌는 TCP/IP 송·수신구조
        2-16. IP 헤더 형식
        2-17. 서브넷 마스크와 CIDR
        2-18. Broadcast IP주소
        2-19. Host 자신을 가리키는 IP주소
        2-20. TTL과 단편화
        2-21. 인터넷 설정 자동화를 위한 DHCP
        2-22. ARP
        2-23. Ping과 PTT
        2-24. TCP와 UDP 개요
        2-25. TCP 연결과정
        2-26. TCP 연결종료 및 상태변화
        2-27. TCP, UDP 헤더형식과 게임서버 특징
        2-28. TCP '연결'이라는 착각
        2-29. TCP 연결과 게임버그
        2-30. 한 번에 끝내는 DNS
        2-31. 웹 기술 창시자와 대한민국 인터넷
        2-32. URL과 URI
        2-33. 굵고 짧게 살펴보는 HTTP
        2-34. 그림 한 장으로 외워서 끝내는 웹 서비스 구조 기본이론
        2-35. WAS와 RESTful API 그리고 JVM
  3. 요약

1. 포스팅 개요

해당 포스팅은 인프런의 널널한 개발자님의 외워서 끝내는 네트워크 핵심이론 - 기초를 수강한 내용들을 정리한 포스팅입니다.

2. 본론

2-1. Layer와 Layered 구조

Layer는 주로 계층을 의미하고, Layered 구조란 계층으로 이루어진 구조를 말합니다.

TMI입니다만, 제가 예전에 네트워크 공부를 잠깐 했었는데, OSI 7 Layer 와 TCP/IP 4계층이 있었습니다.
그때 OSI 7 Layer는 말 그대로 7계층이었고, TCP/IP는 4계층입니다.
이때 각 계층마다 접두사로 L을 붙였었는데, L이 Layer 즉, 계층을 의미하는 걸 이번 기회에 알게됬습니다.

각 계층을 표현하는 접미사 L은 Layer 즉, 계층을 의미한다는 것 참고하시면 좋을 거 같습니다.

2-2. 네트워크와 네트워킹 그리고 개념

어려운 용어를 빼고, 알려주셨는데, 간략하게 말하면 다음과 같습니다.

네트워크 : 관계
네트워킹 : 상호작용
프로토콜 : 규칙

을 뜻합니다.

풀어서 말해보자면, 각 PC가 네트워크(관계)가 이루어지면, 네트워킹(상호작용)이 이루어지는데, 각각 정해진 프로토콜(규칙)에 따라 네트워킹합니다.

(그림이 없다만, 구글에 '토폴로지'라고 검색해보시고, 이미지를 한 번 참고해보시면 위의 말이 조금 와닿으실 겁니다.)

2-3. User mode와 Kernel mode

NIC : 네트워크 인터페이스 카드
Driver : H/W를 제어하기 위한 소프트웨어

NIC가 있다면, Driver가 설치되어야 동작합니다.

이와 같은 그림이 있을 때,
NIC로부터 Driver는 OSI 7 Layer 계층 중, 1,2 계층(Physical, DataLink)에 해당됩니다.
IP는 OSI 7 Layer 계층 중 3계층에 해당하는 Network 계층에 해당됩니다.
TCP는 OSI 7 Layer 계층 중 4계층에 해당하는 Transport(전송)계층에 해당됩니다.
그리고 Socket 이상은 5 계층부터 시작됩니다.

그리고 이전에 널널한 개발자님의 넓고 얇은 컴퓨터 전공지식에서 User mode에는 프로세스(프로그램이 실행되어 메모리에 로드된 상태)가 돌아가고 있다고 했는데, 그림에는 보이는 File(똥글빼이 겁나게 친겁니다.)형태로 돌아갑니다.

네트워크에서는 저 File이 TCP/IP를 추상화시킨 인터페이스인데, 이를 File이라고 하지않고, Socket이라고 합니다.

그리고 여기서 통상 TCP와 IP를 말할 때, TCP/IP << 이렇게 썻는데,
이번에 저도 처음 알았지만, TCP와 IP가 계층이 다르다는 것을 표현하기 위해서 이렇게 표현합니다.

널개님께서 계층 구조의 하위 계층은 전제조건, 존립의존성 등등으로 표현했습니다만,
OSI 3계층 프로토콜인 IP 기반위에 OSI 4계층인 TCP가 있습니다.
(이건 영한님도 HTTP 메서드 강의에서 언급하신거 같습니다.)

여튼 저는 마치 수학의 분수(분자/분모)식 같았습니다.

2-4. OSI 7 layer와 식별자

이번 2-4장에서는 OSI 7 Layer와 미국의 방위성(DoD)에서 나눈 Network 계층을 찍먹해봤습니다.

DoD는 다음과 같이 얘기합니다. (앞의 n 계층의 의미는 OSI Layer의 계층을 의미합니다.)
1~2계층은 Network Access 계층이라고 합니다.
3 계층은 Internet 계층이라고 합니다.
4계층은 Application 계층이라고 합니다.

식별자

각 계층마다 식별자가 있습니다. 우리 나라 사람에겐 식별자로 주민등록 번호가 있듯이, OSI 7 layer에서도 각각의 계층을 구분할 수 있는 식별자가 있습니다.

L2에서는 MAC 주소(Mac Address : 물리적 주소(NIC(네트워크 인터페이스)))가 있습니다. MAC 주소는 랜카드에 붙습니다.
L3에서는 IP 주소가 있습니다. IP 주소는 v4, v6가 있습니다. IP주소는 host에 붙습니다.

L4 계층에서는 PORT 번호가 있습니다. Port 번호는 4계층에 대한 식별자인데 관점에 따라 다르게 3가지로 생각합니다.

  • L2 계층을 주로 다루는 분들(노란 모자를 쓰시고, 전기 줄에서 작업하시는 분들)에게 Port는 인터페이스 식별자라고 생각합니다. 유선 케이블의 단자를 생각하고 말씀합니다.
  • 네트워크를 관리하시는 분들은 Service 를 생각한다고 합니다. 왜냐하면 하나의 서비스를 이용하게 하려면, 각 서비스에 맞는 Port를 개방해야합니다.
  • 엔드포인트에서 컴퓨터를 다루는 사람들에게 Port란, 어? 포트란?? 프로세스를 의미합니다.

각 컴퓨터에서 네트워크를 확인하는 방법은
윈도우에서는 ipconfig, 리눅스에서는 ifconfig 를 사용하시면 됩니다.

2-5. Host는 이렇게 외우자

Computer(혹은 Smart Phone)는 혼자 쓰일 때는 컴퓨터라고 부르지만, Network를 만나면 용어가 달라집니다.

Computer가 Network를 만나면 컴퓨터를 Host(호스트)라고 부릅니다.

Host를 지칭할 때 둘로 나눠지는데,
Network 그 자체를 이루는 Host, 그 Host를 Switch라고 말합니다.
이는 Infra 구조에 해당하는 얘기입니다.

이 Host에는 L3 스위치인 Router가 있습니다.
그리고, 보안 장치에 해당하는 스위치인 IPS가 있고,
관리목적으로 존재하는 Tab, Agreegation 스위치가 있습니다.

반면에, 인프라를 이용하는 Host는 End-point(단말)를 얘기합니다.
End-point에는 클라이언트, 서버, 그리고 클라이언트와 서버 역할을 같이하는 Peer 또한 End-point입니다.

TMI이지만... P2P가 클라이언트&서버의 역할을 같이하는 걸 이제 알았고, 뭔지도 모르면서 P2P 사이트 뭐 이런식으로 얘기했던 학창시절이 잠깐 생각났습니다...

2-6. 스위치가 하는 일과 비용

자동차를 운전할 때 각 교차로가 나오면 목적지를 생각하면서 경로를 선택합니다.
만약 목적지의 위치를 모르고 경로를 선택할 때는 이정표를 보고 선택하며, 또 경로에 따른 비용이 나옵니다.

네트워크도 이와 마찬가지로 교차로가 나오는데 스위치가 이 교차로의 역할을 합니다.
이를 인터페이스를 선택한다고 하고, Switching이라고도 합니다.
이 L3 스위치를 라우터(Router)라고 합니다.

여기서 자동차는 하나의 단위로써 네트워크에선 Packet이라고 합니다.

그리고 각 도로마다 이정표가 있다고 했는데, 이 이정표가 바로 Routing Table입니다.

만약 스위칭을 할 때 Mac Address를 가지고 한다면? 이 스위치는 L2 스위치입니다.
만약 스위칭을 할 때 Port 번호를 가지고 한다면? 이 스위치는 L4 스위치입니다.
스위칭을 할 때 HTTP 프로토콜을 가지고 한다면? 이 스위치는 L7 스위치입니다.

위 그림처럼 윈도우 cmd에서 Routing Table을 확인할 수 있는데, route PRINT라는 명령어를 통해 확인할 수 있습니다.

위 그림처럼 만약 교차로에서 오른쪽에서는 100원, 아래쪽으로는 50원이 든다고 한다면, 보통 저렴한 아래쪽으로 갈 것입니다.

네트워크에서 이러한 비용을 Matric이라고 표현합니다.

2-7. NIC, L2 Frame, LAN 카드 그리고 MAC 주소

네트워크에는 규모가 있습니다.
WAN(Wide Area Network) > MAN(Metropolita Area Network) > LAN(Local Area Network) 순입니다.

  • NIC(Neetwork Interface Card)는 흔히 LAN카드를 의미합니다.
  • 유/무선 NIC이 있지만, 굳이 구별하지는 않고, NIC이라고 할 때가 많습니다.
  • NIC은 H/W 요소이며, MAC주소를 얻습니다.

위 그림은 NIC, 유선, 무선 NIC입니다.

그리고 2-6에서 자동차를 단위를 언급하면서 Packet을 언급했는데, Packet은 L3 의 단위입니다.
L2에서는 단위를 Frame이라고 합니다.
(참고로 L 1에서는 bit입니다.)

그리고, 속도를 얘기할 때 1Gbps에서 b가 소문자인데, b가 소문자라면, bit를 의미합니다.
대문자가 Byte를 의미합니다.
(저는 이 때까지 Byte인줄 알았습니다...ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ)
10Gbps로 가면, 이 때는 광케이블을 사용한다고 합니다.

2-8. 스위치에 대해서

스위치도 여러 종류들이 있습니다.

L2 Access Switch는 End-point와 직접 연결되는 스위치로써, MAC주소를 근거로 스위칭 합니다.

컴퓨터를 스위치에 연결하면, 스위치에 있는 LED가 녹색 불이 켜지면서 깜빡깜빡거리는데 이는 연결이 되었다는 것을 의미합니다.

이 때 연결된 상태를 우리는 Link-up되었다고 얘기합니다.
그럼 연결이 되지않았으면? Link-Down이라고 얘기합니다.

그리고 어떤 랜케이블이 있을 때 그 케이블이 상위 계층의 장비로 가는 케이블이라면, 그 케이블을 uplink라고 표현합니다.
(여기선 라우터로 연결되는 케이블을 뜻하겠네요^^)

L2 Distribution switch는 L2 Access Switch를 위한 스위치입니다.
L2 Distribution switch는 보통 VLAN(Virtual LAN)기능을 제공합니다.

L2 Access Switch가 각 사무실에 배치된다면,
L2 Distribution switch 건물의 한 층에 배치되고,
L3 장비인 Route는 한 건물당 배치된다고 생각하시면 됩니다.

2-9. LAN과 WAN의 경계 그리고 Broadcast

Broadcast

Broadcast는 쉽게 말하면 방송입니다.
반대되는 말은 Unicast입니다.
Unicast는 일대일이지만, Broadcast는 일대다입니다.

방송은 좋은 정보를 줄 때도 있지만, 때로는 방해가 되기도 하기 때문에, 범위를 최소화하는 것이 좋습니다.

Broadcast는 Broadcast 주소라는 특별한 주소가 존재합니다.
이 때 MAC이든 IP로든 모두 존재합니다.

MAC의 경우는 다음과 같습니다.

MAC은 8bit의 수가 6자리로 이루어지기 때문에, 48bit로 구성되어있는데,
이 때 MAC주소를 기준으로 자리수가 전부 이진수 1로 채워진 FF-FF-FF-FF-FF-FF를 MAC주소의 BroadCast라고 합니다.

네트워크에는 출발지와 목적지가 있는데, 만약 목적지의 MAC주소가 브로드캐스트 주소라면, 그건 해당되는 네트워크에 있는 모든 PC에 통신한다는 의미입니다.
그리고 그 순간에는 네트워크 안에 있는 다른 PC들은 통신을 못 합니다.
그렇기 때문에, 브로드캐스트의 범위를 최소화하는 것이 좋습니다.
(브로드캐스트는 마치 밤에 술취한 사람이 조용한 곳에서 고성방가하는 것과 같습니다.)

L2 계층의 통신 단위는 Frame입니다.(스위치는 L2계층 장비입니다.)
Frame에는 Header가 있는데, Header에는 출발지 주소와 도착지 주소가 있습니다.

(위 그림은 정답은 아니고 이해를 돕기 위한 그림이라고 생각하시면 될 거 같습니다.)

OSI 7 Layer 중 1,2계층이 H/W에 속하는 Physical 계층 즉 물리적 게층인데 이 물리적 계층을 기반으로 하는 네트워크를 LAN이라고 생각하면 되고,

3 계층부터는 S/W에 속하는 Logical 계층 즉 논리적 계층이고, 이 논리적 계층을 기반으로 하는 네트워크를 WAN이라고 생각하시면 좋을 거 같습니다.

그리고 이전 강의에서도 언급한 바 있지만, 논리적 즉 Logical한 것을 다른 표현으로 Virtual 즉, 가상이라는 쓰이는데 그 이유는 실체가 없기 때문입니다.

여하튼 이 내용이 정답은 아니지만, 나중에 이해를 할 때 도움이 되실 것이다 라고 말씀하셨습니다.

2-10. IPv4 주소와 기본 구조

IPv4 32bit 구조로 되어있습니다.
32bit는 8bit가 4개가 모인 것입니다.

8bit로 표현할 수 있는 수는 최대값이 255입니다.
이진수로는 1111 1111 입니다. 십진수로는 255이구요.

그리고 만약 1111 1111 형태로 나온다면, (십진수로는 255)
해당 주소는 브로드 캐스트 주소라고 생각하면 됩니다.

윈도우 혹은 MAC에서 ipconfig 혹은 ifconfig를 실행하면 앞자리가 192(혹은 172 호오오옥은! 10)가 나올 것인데, 이는 사설주소입니다.
(사설 주소 관련해서는 강의에 나오지 않는 내용이지만, NAT을 검색해보면 도움될 것입니다.)

IP주소는 32bit를 두 개로 나누게 되는데, 한 부분은 Network ID를 한 부분은 Host ID를 뜻합니다.

Network ID와 Host ID는 우리나라 주소로 마치 다음과 같습니다.
서울시 강남구 역삼동 OO번지 가 있을 때
서울시 강남구 역삼동이 Network ID,
OO번지가 Host ID에 해당된다고 생각하시면 됩니다.

(서브넷 마스크는 후에 나올려나...??)

2-11. L3 IP Packet으로 외워라

Packet은 단위 데이터를 의미합니다.
Packet은 Header와 Payload로 나뉘어집니다.

패킷의 최대크기는 MTU(Maximum Transmission Unit의 약자)인데, 최대 전송 단위를 의미하며 그 크기는 Header와 Payload를 포함하며, 특별한 이유가 없다면, 1500byte입니다.(1500byte는 1.4 KB 밖에 안됩니다.)

Packet을 택배로 비유하면,
Header는 택배의 송장, Payload는 택배의 내용으로 생각할 수 있습니다.

2-12. Encapsulation과 Decapsulation

Encapsulation

Encapsulation(캡슐화)는 러시아의 마트료시카 인형(전통 목각 인형)처럼 데이터를 외부에서 볼 수 없도록 한 것을 의미합니다.

이를 네트워크로 바꾸면 다음 그림처럼 표현할 수 있습니다.

L2 데이터 단위인 Frame 안에 L3 데이터 단위인 Packet이 있고,
L3 데이터 단위인 Packet 안에 L4 데이터 단위인 Segment가 있습니다.
(그 안에 또 있지만, 형태가 달라져서 후에 다룹니다.)

그래서 정리한 그림은 다음과 같습니다.

이 Encapsulation 된 데이터를 꺼내는 과정(캡슐화의 반대과정)을 Decapsulation이라고 합니다.

2-13. 패킷의 생성과 전달

어떤 프로세스가 인터넷을 통해서 데이터를 전달하려고 하는데, 프로세스와 TCP/IP 간에는 Socket이 존재합니다.
전달하려는 데이터를 Socket에 Write(쓰기)를 하는데,
이 때 네트워크 용어로는 write라고 하지않고, send 즉 "보낸다"라고 표현합니다.

데이터를 전달하려 할 때 각 계층(OSI 7 Layer)을 타고 내려가면서 캡슐화가 진행됩니다.
TCP를 만나게 되면, 전달하려는 데이터에 TCP Header가 붙습니다.
TCP Header와 Data가 합쳐진 데이터 단위를 Segment라고 부릅니다.

그리고 또 한층 내려가면, L3 Protocol인 IP Header가 붙게 됩니다.
이 때의 데이터 단위가 packet입니다.
그리고 또 한층 내려가면, L2 Protocol인 Ethernet Frame Header가 붙게 됩니다.
이 때의 데이터 단위는 Ethernet Frame입니다.

이처럼 데이터는 Encapsulation된 후 인터넷을 통해서 데이터가 나가게 됩니다.

※앞에도 언급했었지만, Socket은 파일의 일종으로 kernel mode protocol을 user mode application process가 접근할 수 있도록 TCP/IP를 추상화한 인터페이스입니다.

2-14. 계층별 데이터 단위

L1~L2 수준의 데이터 단위 : Frame(프레임)
L3 수준의 데이터 단위 : Packet(패킷)
L4 수준의 데이터 단위 : Segment(세그먼트)

Kernel mode를 넘어서 User mode 로 가게 되면 Socket이 있고, Socket 수준에서 데이터 단위가 또 나옵니다.
이 때의 데이터 단위는 Stream입니다.

그런데 데이터 단위라고 하기에는 애매합니다.
왜냐하면, Stream은 시작은 있지만, 끝을 알 수 없습니다.
끝을 정하는 것은 프로세스 수준, 즉 애플리케이션 수준에서 정의해버립니다.
Stream은 운영체제 입장에서 연속적으로 이어진 크기를 정확히 알 수 없는 큰 데이터입니다.

그런데, L3의 IP에서 Packet의 최대 단위 크기가 MTU였고, 1500byte 밖엔 되지 않았흡니다.

마찬가지로 TCP에서도 최대 단위크기가 있는데 이는 MSS입니다.
Maximum segment size의 약자로서 최대 세그먼트 크기를 의미합니다.
MSS는 특별한 일이 없으면 1460byte입니다.

만약 Stream의 크기가 4MB라면, MSS의 크기를 훌쩍 넘어버립니다.
이 때는 어떻게 될까요...?

Socket이 타고 내려와서 L4 계층에서 세그먼트화 욉니다.
4MB의 사이즈가 MSS로 잘리면서 분할되는데, 이 분할 되는과정을 가리켜서 segmentation(세그멘테이션)이라고 합니다.
각 조각들은 MTU 사이즈에 맞춰서 인터넷이라는 환경에서 유통하게 됩니다.

※ 참고로 Socket을 생각하면, Stream을 항상 함께 생각하라고 합니다.^^
소켓-스트림 소켓-스트림 소켓-스트림.....

2-15. [※중요] 이해하면 인생이 바뀌는 TCP/IP 송·수신구조

이번 챕터는 복습과 예습차원에서의 전체적인 흐름에 대한 내용이었습니다.

데이터를 송신하는 쪽에서 전달할 데이터를 보조저장장치(HDD, SSD)에서 파일을 block 단위로 꺼내서 프로세스의 Buffer로 가져옵니다.

프로세스의 Buffer에 저장된 block은 Socket의 Buffer로 write하게 되는데, 네트워크에서는 이 과정을 send라고 합니다.
Socket의 Buffer에 저장된 block이 TCP의 데이터 단위인 세그먼트의 MSS 단위로 나눠지게 되고, 나눠진 세그먼트들에는 순서가 붙습니다.

각 세그먼트들은 각 계층을 따라 Encapsulation되면서 수신측으로 전달되어 도착하게 됩니다.

수신측에서는 Encapsulation된 데이터를 각 계층을 따라 Decapsulation하고, 받은 세그먼트들을 수신측의 Socket의 Buffer로 담게됩니다.
그리고 수신측의 Socket의 Buffer에 담긴 세그먼트들은 수신측의 프로세스 Buffer로 이동되는데 이 이동되는 과정을 Receive라고 합니다.
(송신측에서는 Send였지만, 수신측에서는 Receive인 것입니다.^^)

그리고 이 TCP 통신 과정에서 4가지의 장애가 발생합니다.

  1. Loss
  2. Re-Transmission
  3. Out Of Order
  4. Zero Window

Loss

Loss는 통신과정에서 데이터의 유실을 의미합니다.
이는 네트워크에 장애가 발생했음을 의미합니다.

Re-Transmission

Re-Transmission은 조금 복잡한데...
송신측에서 수신측으로 데이터를 보내면
수신측에서는 받았다는 신호를 보내줘야 합니다.

만약 송신측에서 수신측으로부터 받았다는 신호를 못 받으면 이미 보낸 데이터를 재전송합니다.
그런데 간발의 차로 송신측에서 데이터를 보내자마자 수신측에서 데이터를 받았다는 응답을 송신측에서 받는 경우가 있습니다.
그리고 수신측에서는 이미 받은 데이터가 또 오는 경우가 있을 수도 있습니다.

이런 경우를 Re-Transmission 이라고 합니다.

이 경우는 네트워크의 문제일 수도 있고, End-Point 간의 합이 맞지 않아서 나는 경우도 있습니다.

Out Of Order

Out Of Order는 순서가 이상하게 올 때의 장애를 말합니다.
만약 1,2,3,4 순서대로 데이터가 와야하는데, 1,2 다음에 3번이 아니라, 4번이 오는 경우가 있습니다.
이런 경우처럼 순서가 맞지 않는 경우를 Out Of Order이라고 합니다.

이 떄 운영체제에서 일정수준에서 보정을 하게 된다는 내용을 참고하시면 좋을거 같습니다.

이는 네트워크의 문제로 발생하는 장애입니다.

Zero window

데이터를 받는 수신측에서는 받았다는 신호를 송신측으로 내보내는데, 이 때 여유공간도 함께 보내게 됩니다.

여기서 여유공간이란, 송신측으로부터 받을 수 있는 데이터의 크기에 대한 공간을 의미합니다.

네트워크는 안정적이지만, 수신측의 PC가 용량이 꽉 찼을 발생하는 장애입니다.

2-16. IP 헤더 형식

ip 패킷의 헤더를 그림으로 나타내면위와 같습니다.

시작점부터 패킷 끝까지 사용할 수 있는 공간은 mtu(maximum transmission unit)로 최대 1500byte까지 사용할 수 있는데,
header가 대략 20byte로 1480byte를 사용할 수 있습니다.

각 헤더는 다음과 같습니다.

version

version은 IP Protocol의 버전을 의미하는데, 현재 IPv4를 다루므로 그림상 4가 저장되어있습니다.

IHL(internet header length)

인터넷 헤더의 길이를 의미하는데 보통 그림과 같이 32bit가 5행(오른쪽에 20bytes표시를 보면 알 수 있습니다. 그림상 그렇습니다.^^)으로 되어있습니다.
32bit는 4byte이고, 5행이므로 4*5를 하여 20byte의 크기가 적혀있습니다.(그림상 입니다.^^)

TOS(Type Of Service)

(강의에서 다루는 내용은 아닙니다.)
각 블로그에서 살펴본바
"라우터에서 IP 데이터그램을 처리할 때 우선순위 결정에 사용된다."

라고 하고,

참고블로그

혹은

위와 같이 설명하고 있고,
참고블로그

혹은

"TOS(Type of Service): ToS는 우선순위를 나타내는 3비트의 Precedence 및 4비트의 서비스 유형 지정 비트, 그리고 사용되지 않은 1비트이다. ToS 필드를 사용하여 라우터나 호스트 등의 장치에서 패킷 처리에 대한 우선순위(QoS)를 설정할 수 있는데 현재는 DSCP(Differentiated Serviecs Code Point) 필드로 정의되어 있다."

라고도 합니다.

참고블로그

참고 네이버 블로그 : 2008년

8bit를 할당받고, 1bit는 사용하지않고, 3bit는 우선순위를, 4bit는 서비스 유형을 지정하는데 사용합니다.

Total length

Packet의 길이를 의미합니다.

Packet의 최대 크기는 이론상 16bit입니다.
16bit는 2의 16제곱이고 2의 16제곱은 65535이므로 64K가 패킷의 크기를 나타낼 수 있는 가장 큰 수입니다.
보통 Packet의 길이에 Header의 길이를 뺀 값을 말합니다.

단편화와 관련된 것들

단편화는 예를 들어 패킷의 크기가 MTU가 1500인데, 다른 네트워크에서는 MTU가 1300입니다.
이 때 1500의 크기를 가지는 패킷은 1300의 MTU에 맞게 패킷을 잘라야 됩니다.
이 "패킷이 잘리는 현상을 단편화가 난다."라고 표현합니다.

각 요소 설명은 넘어갔지만, 나중에 다뤄주실 거 같습니다만, 일단 하나의 블로그에서 가져온 정보에 의하면 다음과 같습니다.

참고블로그는 여기를 눌러주세요.]

(반말을 존댓말로 바꿔서 설명합니다^^)

Identification & Flags & Fragment offset

Identification

  • 16비트의 식별자 필드는 데이터그램이 전송된 발신지 호스트를 구별합니다.

Flags

  • 3비트의 플래그 필드는 3가지 플래그를 정의합니다.
  • 첫번째 비트는 사용하지 않습니다.
  • 두번째 비트는 0일 경우 단편화 가능, 1일 경우 단편화 불가능을 뜻합니다.
  • 세번째 비트는 0일 경우, 분할된 마지막 패킷이라는 뜻이고, 1일 경우 뒤에 남은 게 있다는 뜻입니다.

Fragment offset

  • 13비트의 단편화 오프셋 필드는 전체 데이터그램에서 해당 단편의 상대적인 위치를 나타냅니다.

TTL(Time To Live)

그림상 8bit와 같이 최대크기가 255입니다.
이 값이 0이 되면 해당 패킷이 버려집니다.
네트워크 통신 과정에서 HOP이라는 단위를 지날 때마다 감소하게 됩니다.

GPT는 "패킷이 네트워크를 통해 전달될 때, 해당 패킷이 네트워크에서 살아있을 수 있는 시간을 나타내는 값"이라고 설명합니다. ^^

Protocol

L3 Header안쪽 payload에 또 다른 Header가 올 수 있는데,
이 헤더를 어떤 프로토콜로 해석해야 하는지에 대한 값이 들어옵니다.

프로토콜 번호는 IANA에서 프로토콜마다 부여한 고유번호를 확인할 수 있습니다.

Header checksum

검사값을 이용한 검사합입니다.
보안성은 없습니다.
데이터, 패킷이 송수신되는 과정에서 손상이 일어난 경우를 검사하기 위한 체크섬 검사값입니다.

Source address

출발지 IP 주소를 나타냅니다.

Destination address

도착지 IP 주소를 나타냅니다.

해당 Header정보는 WireShark라는 프로그램을 이용해서 좀 더 정확히 알 수 있습니다.
그런데 WireShark를 쓰려면 16진수와 친해진 상태에서 보시는 것이 좋습니다.

2-17. 서브넷 마스크와 CIDR

위의 그림에 보시면, 24bit(왼쪽)와 8bit(오른쪽) 사이에 하나의 막대기로 영역이 분리되어 있습니다.
이 선을 기준으로 네트워크 주소와 호스트 주소가 나눠집니다.

여기서 서브넷 마스크의 개념이 나오는데 서브넷 마스크를 가지고,
네트워크 주소가 구해집니다.

위의 그림처럼 표현해보면,

1100 0000 | 1010 1000 | 0000 0000 | 0000 1010 : 주소
1111 1111 | 1111 1111 | 1111 1111 | 0000 0000 : 서브넷 마스크(24bit)

이와 같은데, 이 실제 주소의 값과 서브넷 마스크를 and 연산한 값이 현재 주소의 네트워크 주소입니다.

서브넷 마스크와 and연산을 할 때, 1인 것만 내려주면 되는데,
(당연히 and 연산이라 서브넷 마스크는 죄다 1이고, 그 외 1에 해당하는 것만 해주면 되니깐요 ^^)
한 번 해보겠습니다.

1100 0000 | 1010 1000 | 0000 0000 | 0000 1010 : 주소
1111 1111 | 1111 1111 | 1111 1111 | 0000 0000 : 서브넷 마스크(24bit)

1100 0000 | 1010 1000 | 0000 0000 | 0000 0000
.2^7+2^6 | 2^7+2^5+2^3 | 0 | 0 |
128+24 | 128 + 32 + 8 | 0 | 0 |

192.168.0.0 이 실제주소인 192.168.0.10에 대한 네트워크 주소입니다.

이 서브넷 마스크를 가지고 연산을 하는 것을 Mask 연산이라고 합니다.

원래는 앞에 처음 8bit가 어떻게 시작하냐에 따라 IP주소마다 클래스를 나눴는데, 여즘은 그렇게 안 쓴다고합니다.
(여즘 오타아닙니다.)
요즘에는 CIDR(Classless Inter-Domain Routing) 표기법을 쓰는데, 말처럼 클래스 개념없이 표기한다는 것입니다.

원래는 그냥 실제 주소밑에 서브넷마스크(ex:255.255.255.0)을 일일이 썻다는데, 지금은
192.168.0.10/24이런 식으로 표기한다고 합니다.

예전의 표기에 대한 예시는 다음과 같습니다.

192.168.0.10
255.255.255.0

이렇게 썻다고 합니다..

그리고 나눠진 네트워크 안에서 또 네트워크를 나누는 서브넷팅 개념도 있다고 하는데, 널널한 개발자님의 유튜브 채널에서 다루신다고 하니 한 번 보셔도 좋을 것 같습니다.
(저는 배웠습니다.. 부산에서 ㅎㅎ)

2-18. Broadcast IP주소

IP 주소 부분 중 네트워크 주소를 제외한 호스트 주소 부분이 전부 1로 다 채워진 주소를 Broadcast 주소라고 합니다.

즉 쉽게 말해서 위에서 말한 예시와 같이

192.168.0.10 이 host주소이고, 네트워크는 24bit의 서브넷마스크를 사용해서 네트워크 주소를 구한 결과는 192.168.0.0 이었습니다.

따라서 네트워크 주소를 제외한 호스트 주소 부분이 전부 1로 다 채워진 주소가 Broadcast 주소라고 했는데, 무슨 말이냐.

192.168.0.1111 1111 => 192.168.0.255 입니다.
마지막 8bit만 2진수로 표기했는데, 다 더하면 255입니다.

192.168.0.10이 속한 네트워크의 브로드캐스트 주소는 호스트 주소 부분이 전부 1로 채워진 192.168.0.255가 바로 브로드캐스트 주소입니다.

위 그림은 설명중에 제가 캡쳐한 그림인데,
어떤 PC에서 3.3.3.3을 도착지로 packet을 보낸다고 가정하면, 3.3.3.3의 PC를 찾아서 packet이 도착하게 됩니다.

그런데, 만약 브로드캐스트 주소를 준다면, 처음 나오는 스위치에서 일단
packet을 받고, 연결된 모든 곳에 Packet을 뿌리고, 또 다시 받은 스위치에서
packet을 받고, 연결된 모든 곳에 Packet을 뿌리고.. 등등 그렇게 됩니다.
(도르마무가 생각납니다만,)

도착지의 IP를 브로드캐스트 주소로 준다는 것은 네트워크에 속한 모든 IP에 데이터를 전달한다는 것이기 때문에 각 장비는 연결된 모든 곳에 패킷을 전달합니다.

그래서 브로드캐스팅을 자주하면 효율이 좋지 않습니다.
브로드캐스팅 도달 범위를 일정 수준에서 통제해야 한다고 합니다.
브로드캐스팅이 많으면 많을 수록 네트워크 장비의 전체 부담이 많이 듭니다.
pc같은 경우엔 한 번만 받으면 되지만, 네트워크 장비는 계속 뿌려줘야하기 때문이죠.

다음으로 네트워크에 사용하지 못하는 주소가 있습니다.
네트워크 주소와 브로드캐스트 주소입니다.

TMI이지만, 네트워크를 배웠을 때, 2^bit 수만큼에서 브로드캐스트와 네트워크 주소를 제외하여 2^n - 2개가 사용가능한 네트워크의 주소라고 배웠던 기억이 납니다.

다음은 Host 자신을 가리키는 IP주소입니다.

2-19. Host 자신을 가리키는 IP주소

Host 자신을 가리키는 IP주소는 결론적으로 로컬호스트(localhost)를 의미하며, IP주소는 127.0.0.1 입니다.

위의 그림은
만약 host의 PC 주소가 192.168.0.10이라고 가정하고,
client의 역할을 하는 프로세스와 server의 역할을 하는 프로세스가 있다고 가정했을 때,
client 역할을 하는 프로세스에서 server 역할을 하는 프로세스로 데이터를 전달할 때
192.168.0.10의 주소로 통신을 요청해도 되지만, host 자신을 가리키는 주소인 127.0.0.1로 통신을 해도 상관없습니다.

그리고 위의 그림에와 같이 자기 자신 프로세스끼리 TCP/IP 통신을 하지만, Driver를 거쳐가는 통신을 하지 않습니다.

2-20. TTL과 단편화

"인터넷은 라우터의 집합체라고 할 수 있는 논리 네트워크이다."라고 널널한 개발자님은 인터넷에 대한 사견을 말씀하셨습니다.
(사견이라고 하셨으니, 정답은 아니라고 하신겁니다.)

그리고 L3스위치와 라우터를 비교함에 있어서 사람마다 생각이 다릅니다.
라우터와 L3 스위치를 나누는 것은 의미가 없다고 하는 사람도 있고,
라우터는 L3 스위치에 포함되는 것이다 하는 사람도 있고,
반대로, L3 스위치가 라우터에 속한 것이다 라고 하는 사람도 있다고 합니다만,

널널한 개발자님은 역시 "정답은 없다"고 하시면서 본인은 라우터와 L3 스위치를 나누는 것은 의미가 없는 것 같다고 말씀하셨습니다.

TTL

TTL은 Time To Live의 약자입니다.
TTL은 라우터에서 라우터로 지날 때의 단위를 hop이라고 하는데, 그 hop을 지날 때마다 TTL의 값이 1씩 감소하다가 0이되면 패킷이 버려집니다.

Packet이 도착지에 도착하지 못하고 네트워크상에 살아있다면 좀비 패킷들이 넘쳐나고 네트워크에 부하가 많이 일어나서 네트워크가 다운될 수 있을 것인데 그걸 방지해주는 것이 TTL 입니다.

단편화

단편화는 예를 들어 네트워크 중 MTU가 1500인 상태로 통신이 되었다가 어떤 장비에서는 MTU가 1500보다 작은 1300, 1400 등 단위가 작아지는 경우가 나옵니다.
이 때 통신되던 MTU보다 더 작은 크기로 패킷이 잘려져야 하는데, 그 잘리는 과정을 단편화라고 합니다.

그리고 MTU가 특정 구간에서 통신되던 MTU의 크기보다 작아지면 단편화가 일어난다고 하였는데, 만약 1500MTU의 패킷 한 개가 전달되고 있는 과정에서 특정 구간에서 MTU가 1400이라면 해당 패킷은 2개로 나눠지고, 2개로 나눠진 패킷은 수신하는 곳에서 조립하게 되어있습니다.

네트워크 중간에 패킷을 조립하는 기능을 가진 네트워크 장비가 있을 수도 있지만, 통상적으로 수신측에서 조립하게 됩니다.

이 그림은 위의 설명에 대한 그림입니다.

보통은 MTU가 1500이고, 1500이 아닌 경우가 거~~의 없는데 1500이하로 내려가는 경우가 가끔 있습니다.

바로 VPN을 이용하면서 IPSec가 적용될 때 MTU가 1500보다 작아집니다.

2-21. 인터넷 설정 자동화를 위한 DHCP

ISP
Internet Service Provider로 인터넷에 접속하는 수단을 제공하는 주체를 가리킵니다.
(출처 : 구글링)

보통 인터넷을 사용하기 전에 설정해줘야 하는 것들이 있는데, IP주소 같은 경우는 ISP에서 제공하는 IP를 써야합니다.

그리고 PC에서 인터넷을 사용하기 위해서 다음의 4가지를 정해주어야 합니다.

IP주소, Subnet mask, Gateway IP주소, DNS 주소입니다.

아마 아래의 화면을 보셨을 것입니다.

이렇게 설정해줘야 하는데, 보통은 수동으로 설정하지 않고, 자동으로 설정되게 합니다.
그 자동으로 설정되게 하는 것이 DHCP입니다.

DHCP(Dynamic Host Configuration Protocol)

DHCP를 통해서 동적으로 IP를 설정되기 위해서는 DHCP서버가 브로드캐스트 도메인 내에 있어야 합니다.

  1. 어떤 HOST PC가 DHCP를 이용하여 IP주소를 발급받고싶을 때 HOST PC에서는 네트워크로 브로드캐스트 패킷을 보냅니다.
  2. 브로드캐스트 패킷을 보내어서 DHCP 서버가 있는지 확인합니다.
    // 이 때 중간에 스위치들도 브로드 캐스팅을 하면서 DHCP 서버를 찾습니다.
    // 만약 DHCP 서버가 아니라면, 수신을 하더라도 응답하지 않습니다.
  3. DHCP가 서버를 찾았다면 HOST는 DHCP 서버한테 해당 IP주소를 계속 써도되는지 물어봅니다.
  4. DHCP서버에서는 저장된 IP Pool을 통해서 확인한 후, HOST에게 사용 여부를 알려주게 됩니다.
    // 이 때 IP만 주는 것이 아니라, 게이트웨이 주소, DNS서버 주소, Subnet mask도 함께 넘겨보내줍니다.

해당 그림은 위의 설명에 대한 그림입니다. ㅋㅋㅋㅋㅋ

2-22. ARP

보통 컴퓨터에서 주소를 얘기하면, IP주소와 MAC주소를 가지고 얘기합니다.
IP는 레이어로 치면 L3, MAC주소는 레이어로 치면 L2입니다.

ARP(Address Resolution Protocol)는 IP주소로 MAC주소를 알아내려 할 때 활용하는데 보통의 경우 PC를 부팅하면 Gateway의 MAC주소를 찾아내기 위해 ARP Request가 발생하며, 이에 대응하는 Reply로 MAC주소를 알 수 있습니다.

위 그림처럼 host는 192.168.0.100 게이트웨이는 192.168.0.1이라는 주소를 가지고,
Host PC가 8.8.8.8을 주소로 가지는 구글에 접속한다고 가정했을 때,

host PC가 구글을 접속하기위해 internet을 접근하려면, host PC는 반드시 게이트웨이의 MAC Address를 알아야합니다.

그래서 host PC에서 설정한 Gateway의 주소를 가지고 브로드캐스트 통신을 하는데
"우리 네트워크에서 내 PC에 설정된 Gateway 주소를 가지고 있는 Host가 있니~?" 라는 의미의 통신을 하는데
이 때 ARP Request도 같이 하게 됩니다.

브로드캐스트 통신을 받은 HOST들은 반응이 없다가 GW만 반응을 하게됩니다.
그래서 게이트웨이는 ARP Request에 대한 Reply를 함께 하게 됩니다.

그 Reply에 게이트웨이의 MAC주소를 함께 응답합니다.

그리고 HOST가 Packet을 보내게되는데,
IP주소는
출발지는 host자신(여기서의 예시는 192.168.0.100)의 IP주소를,
목적지는 구글에 해당하는 8.8.8.8의 정보를 실어보냅니다.
(강의에선 네이버 3.3.3.3을 예시로 들었는데, 다르게 하려했다만, ㅋㅋㅋㅋㅋ;;)

그리고!!

그 앞에 L2 Frame의 데이터단위에 패킷을 감싸서 보내는데 L2 Frame에는 MAC주소의 정보가 들어있습니다.
L2 Frame의 Header에 출발지 Host의 MAC주소는 192.168.0.100 HOST의 MAC주소를 적습니다.

그리고!! 목적지는 구글서버의 8.8.8.8 서버의 MAC주소가 아니라,
현재 HOST PC가 속한 네트워크의 게이트웨이의 맥주소를 적어 패킷에 실어보냅니다.

그리고 게이트웨이는 L2Frame이 벗겨진 IP 패킷의 헤더를 보고, 적혀있는 목적지로 패킷을 실어보냅니다.

※참고
arp -a을 윈도우 cmd에 쳐보면 MAC Address의 캐시가 나옵니다~

2-23. Ping과 PTT

Ping

  • 유틸리티(그냥 프로그램)는 특정 Host에 대한 RTT(Round Trip Time)을 측정할 목적으로 사용됩니다.
  • ICMP(Internet Control Message Protocol)을 이용하여 RTT(Round Trip Time)을 측정합니다.
  • Dos(Denail of Service) 공격용으로 악용되기도 합니다.

위에는 개념적인 얘기입니다만, 우리가 lol을 했을 때,
게임이 갑자기 게임이 느려지고, Tab을 눌러보고, 한 사람의 통신상태가 빨갛게 되면 흔히 말했던 게
"님 Ping 왜그럼? 엄마없음?" 하면서 부모님의 안부를 여쭤보며 가슴이 따뜻했던 적이 있을 것입니다.

Ping은 RTT 즉 네트워크의 회신 속도를 측정하는 프로그램입니다.

그래서 사람들끼리 게임을 하는데, 유저 네트워크 속도가 전체적으로 느리거나 할 때, 게임에서는 유저들간의 동기화를 하향 평준화할 것인지를 게임사에서 정한다고 합니다.

그렇다고 합니다... 대충 알아들었습니다. 이게 주 내용은 아니라서...)

따라서 Ping이 이상하다는 것은 정확히 말하면,
"Round Trip Time 즉 네트워크의 회신 속도가 오래 걸린다."고 표현하는 게 맞습니다.

Ping은 Dos 공격용으로 악용할 수 있습니다.
어떤 유저가 CPU 점유율을 100퍼센트까지 올려서 핑을 서버에 미친듯이 보내면,
서버는 정상적인 기능을 하지 못하고, 서버에 접속한 유저들은 서비스를 제대로 이용하지 못합니다.

위의 그림은 네트워크의 회신 속도(Round Trip Time)에 대해서 설명하며 보여준 그림인데,
네트워크의 회신 속도(Round Trip Time)는 통신하는 Host간의 물리적인 거리가 아니라, 네트워크의 속도가 값을 좌지우지 합니다.

강의에서 언급해주고 가는 내용입니다만,
Ping Utility라는 것이 있습니다.
Ping Utility는 Echo Request를 보내는데,
어떤 A라는 PC가 일정길이의 데이터라는 B PC로 보내는데,
Echo Request는 수신측에서 데이터를 받은 그대로 Response를 돌려달라고 요청하는 것입니다.

그래서 A PC가 B PC에 123456789를 보냈다면,
B PC가 A PC에 그대로 123456789를 응답합니다.

2-24. TCP와 UDP 개요

  • TCP에만 연결(Connection, Session) 개념이 있습니다.
    • TCP의 연결은 '논리적'인 개념입니다.
    • 논리적인 연결을 Virtual Circuit이라고도 표현합니다.
      • "논리적"이란 것은 가상(virtual)과도 같은 의미로도 쓰인다고 언급했었는데, 그 이유는 L3에 해당하는 OSI Layer 3계층부터는 H/W가 아닌 S/W에 속하는 영역이기 때문입니다.
        따라서 TCP는 L4 계층이기 때문에 Virtual Circuit으로 표현될 수 있습니다.

※참고로 Circuit은 전기 회로를 의미합니다.

  • 연결은 상태(전이) 개념을 동반합니다.
    • 전화로 비유하면 전화는 전화 연결 '전'과 '후'가 있는 것처럼 TCP 연결도 연결 '전'과 '후'가 있습니다.

연결은 결과적으로 순서번호로 구현됩니다.(널개님의 개인적인 사견입니다.)

아래엔 위 그림에 대한 설명입니다.
(못 알아보시겠죠? 저도 나중에 못 알아보다가, 밑에 읽어보고 기억날 것 같습니다.^^)

TCP는 클라이언트와 서버로 구성이 됩니다.
Client는 연결을 하는 주체고,
Server는 연결을 대기하다가 받는 주체입니다.

Server는 소켓을 연결을 대기하고 있습니다.

Client 측에서는 PID를 가진 프로세스가 Socket을 생성해서 오픈합니다.
그러면 운영체제 측에서 해당 Socket에 TCP Port번호를 부여합니다.
TCP Port번호는 운영체제가 임의로 부여합니다.

Server 측에서도 PID를 가진 프로세스가 Socket을 생성해서 오픈하고, 연결 대기를 합니다.

따라서 클라이언트가 서버로 TCP 통신을 하려면 기본적으로 IP를 알아야 하고, Port 번호를 알아야 합니다.

만약, 서버가 연결 대기 중이 아니라면?

서버의 운영체제 측에서 연결이 되지 않는다는 의미의 응답을 합니다.

2-25. TCP 연결과정

3-way handshaking

세로 선은 타임라인입니다. 아래로 갈수록 시간이 흘러간다는 의미입니다.

그리고 그림에서 1번과정, 2번과정 / 2번 과정, 3번 과정에서 왼쪽(1번, 2번)과 오른쪽(2번, 3번)에서 어떤 구간을 가리키는 빨간 화살표가 있는데, 이 구간이 RTT(Round Trip Time) 바로 네트워킹 속도를 의미합니다.
이전 내용에선 ping 얘기와 더불어서 나온 개념입니다 ^^

SYN은 Synchronization의 약자입니다.


// 아래 설명에 나오겠다만, 위의 그림 중 왼쪽에 빨간 작은 글씨 1000이 클라이언트에서 뽑은 시퀀스 넘버, 오른쪽에 있는 4000이 서버에서 뽑은 시퀀스 넘버입니다.

// 먼저 연결하려는 PC쪽에서 시퀀스 넘버를 생성하는데, 랜덤으로 생성합니다.
  // 클라이언트는 자신이 생성한 시퀀스 넘버와 같이 서버로 통신 요청을 보냅니다.
// 이 때 서버는 연결 대기 중에 요청을 받고 응답을 보냅니다.
  // 이 때 클라이언트로부터 요청을 잘 받았다는 표시를 하기 위해서 클라이언트가 보내준 시퀀스 값에 1을 증가시켜 ACK를 보냅니다.
  // 그리고! 그 전에 서버가 자신의 랜덤 시퀀스 넘버도 뽑아놓고 연결을 대기하는데, 클라이언트의 시퀀스 넘버에 1을 더한 값과 ACK를 보내고,
  // 자신이 이미 뽑아놓은 시퀀스 넘버를 클라이언트에게 SYN을 보내며 같이 보냅니다.

// 그리고 서버의 SYN을 받은 클라이언트는 서버의 시퀀스 넘버에 1을 더하여 ACK를 서버로 보냅니다.

중요한 건 시간차가 있습니다.

위의 줏'통신이 이루어집니다만,
클라이언트는 서버로 연결을 시작하여 서버로부터 SYN+ACK를 받으면 연결이 되었다고 간주합니다.

그런데 서버는 연결이 완료돼었다고 판단하지 않습니다.
서버는 클라이언트로부터 최종 ACK를 받으면 연결이 되었다고 간주합니다.

TCP 연결의 실체같은 것은 사실 없습니다.

이 과정에서 가장 중요한 것은 서버와 클라이언트 간에 Sequance 번호를 교환하는 것입니다.
뿐만 아니라, 정책 교환도 하는데, 그 중에서 가장 중요한 것은 MSS(Maxium Segment Size)가 얼마인지도 교환합니다.

만약 클라이언트의 MSS가 1480이고, 서버의 MSS가 1400이라면, 클라이언트는 MSS의 규격을 서버의 MSS에 적합하도록 낮추고 요청을 보내게 됩니다.

2-26. TCP 연결종료 및 상태변화

TCP 연결 종료 과정(4-way-handshaking)

연결 종료 과정에 대한 그림입니다.
특별한 이유가 아니라면, 보통 클라이언트의 행동이 Active합니다.
즉, 연결을 하는 주체가 클라이언트이고, 연결을 끊는 주체도 클라이언트입니다.

연결을 종료하는 과정은 다음과 같습니다.
(참고로 연결 중이어야합니다!)


// 클라이언트는 연결 종료를 위해 서버로 **FIN+ACK**을 보냅니다.
  // 그리고 ESTABLISHED에서 FIN_WAIT상태로 변경됩니다.

// ESTABLISHED 상태인 서버가 클라이언트로 ACK를 보냅니다.
// 이를 받은 클라이언트는 ACK를 받지만, FIN_WAIT1 혹은 FIN_WAIT2 라는 의미처럼 ACK가 아니라, FIN을 받을 때 까지 기다립니다.
// 그리고 클라이언트가 서버로 ACK를 보내게 되어 서버도 클라이언트와의 연결을 종료합니다.

대강 이렇습니다.

그런데 그림에서 보면, TIME_WAIT가 있습니다.
TIME_WAIT는 보통 연결을 종료하기 직전에 발생합니다.

그리고 TIME_WAIT가 발생한 후에 시간이 지나 CLOSE 상태로 넘어가는데 이 때 Socket이 회수됩니다.
즉, CLOSE 상태가 되면서 Socket이 회수됩니다.

예를 들어, 사용 중인 소켓이 100개에서 CLOSE 상태가 되면 99개가 되는데 이 때 회수한 Socket을 다시 사용할 수 있습니다.

이런 것도 있다고 하니 참고하면 좋을 거 같습니다 ^&^.

2-27. TCP, UDP 헤더형식과 게임서버 특징

TCP

위의 그림은 32bit 단위로 표현되고 TCP 헤더에 대한 그림입니다.

Source port & Destination port

출발지 포트와 도착지 포트를 가리키는 것이고, 16bit인 거 처럼 2^16 즉 0~65535번까지 쓸 수 있습니다.
0번과 65535번 port 외엔 다 사용가능합니다.

그리고 well known port라고 있습니다. 잘 알려진 포트라는 것인데 보통 port 번호를 부여할 때 1024번까지는 피해서 부여해라고 하는데, 그 이유가 이미 지정된 port라서 그렇습니다.
예를 들면, http 80, https 443, ssh 22, ftp 20,21(udp, tcp 일때 다름) 이와 같은 것이 있습니다.
(참고로 예시는 제 머리에서 나온거, ftp 두 개의 port가 20,21이 맞는지 구글링했습니다. 강의와 무관합니다.)

Sequence Number

3-way-handshake 중에 언급된 내용인데, Sequence Number는 위의 그림에서 빨간 영역에서의 데이터의 길이가 있고, 그 데이터의 길이 byte단위로 있을 것입니다.

기존의 Sequence Number에 데이터의 크기를 더한 값이 저장되어 있습니다.

Acknowledgment number(if ACK set)

ACK라는 말처럼 Syn의 Sequence Number에 1을 더한 값이 저장되어 있습니다.

Data offset

데이터에 옵션이 있는지 없는지 여부와 TCP 세그먼트 페이로드의 위치를 계산할 때 사용합니다.
IP Header에서 IHL과 비슷한 개념입니다.

flag value(플래그 값)

이 영역을 얘기합니다.
TCP의 상태를 결정하는데, SYN이 가는지, ACK가 가는지, FIN이 가는지에 대한 정보가 담겨있습니다.
이 안에 9개의 영어가 다 SYN, ACK, FIN 외에 상태를 나타내고 있습니다.

RST는 리셋, PUSH는 네트워크 통신 중 버퍼링을 하는데, 버퍼링을 하지말고, 보내자는 의미로 쓰여집니다.

다른 영역은 혼잡제어 영역입니다.
(하~ㄴ참) 위에서 언급한 장애 유형에 대해 얘기했는데, 그 장애 유형을 제어하기 위한 필드들입니다.
(다룰 게 너무 많기 때문에 언급만 하고 가셨습니다.)

Window Size

여분의 공간을 의미합니다.
그래서 Window Size가 0이 되면 Zero-Window 장애가 발생합니다.

Checksum

데이터가 훼손되었는지 계산할 때 쓰이는 검사값입니다.

UDP

TCP에 비해 정말 뭐가 없습니다.
Port번호 밖에 없습니다.
그리고 길이가 얼마인지? 그리고 Checksum...
끝입니다.

게임 같은 경우는 유저간의 동기화가 굉장히 중요합니다.

ping 얘기를 하면서 한 명이라도 느리게 되면, 네트워크 속도를 하향 평준화해서 제어한다고 했었는데,
TCP를 이용하여 게임서버를 동기화하게 되면 거의 하향 평준화됩니다.

그래서 보통 게임서버는 동기화를 위해서 UDP를 이용합니다.

게임하다가 한 명이 느려져서 다 같이 느려지는 것보다, 몇 명이 느려지는 것이 더 괜찮을 것입니다.
그리고 게임서버를 개발하는 입장에서는 TCP가 구현한 혼잡제어 로직을 UDP 기반으로 구현해버리면 됩니다.
그리고 TCP는 중간에 뭐가 없다면 굳이 받으려고 기다리는 경우가 있습니다.
그래서 게임서버는 UDP를 사랑한다고 합니다.

ㅋㅋ;;
흠... 왕년에 메이플을 했을 때, 한 유저가 제 뒤에 있다가 갑자기 화면 끝에 가더니 워프를 탔는지 사라졌습니다...
"저놈 버그 쓰네..?"라고 생각했지만, UDP 통신때문이었네요.. 하하하
제 컴퓨터가 한 때 똥컴이라 불리던 '조선컴'이었던 거였네요 하하하~~

2-28. TCP '연결'이라는 착각

만약 파일 다운로드 중 LAN 케이블을 분리했다가 다시 연결하면 TCP연결은 어떻게 될까요??
여기서 TCP 연결은 4계층의 연결을 의미합니다.
L1의 수준에서 LAN 선을 뽑는다는 건데...

결론부터 말하면 TCP 연결은 유지됩니다.
(얼마나 오래 뽑았는가가 관련되어있긴합니다.)

그런데 이 부분에 대해서 RFC의 표준 문서와 운영체제에서의 구현부분이 다릅니다.

이러한 차이때문에 소켓 프로그래밍을 하시는 분들은 연결(Connection)이 되어있는지를 지속적으로 확인합니다.
(3-way-handshake로 연결이 되었음에도 불구하고입니다.^^)
계속해서 재확인하는데, 이 재확인하는 과정을 HeartBeat라고 합니다.

HeartBeat는 비유하자면

A와 B친구끼리 통화를 하는데,
A는 밤 11시에 하소연을, B는 굉장히 졸린 상태에서 누운 상태로 A의 전화를 받습니다.

A가 얘기를 마아아악 하다가 A가 쌔~한 기분이 들면서 말합니다.
"야! 자냐?!"

이처럼 B가 A의 말을 듣고있는지 확인하는 것과 유사한 것입니다.

혹은, 전화가 끊어졌지만 끊어졌는지 모르고 혼자 계속 말하는 경우도 있습니다.
그러한 것처럼 LAN선은 뽑았지만, L4 연결은 일정시간동안 유지됩니다.

그럼 얼마나 지속될까...
RFC 문서를 보면 되는데, 아래의 사진에서 확인할 수 있습니다.

하지만!

운영체제가 그렇지 않습니다.
운영체제는 바로 끊어버립니다....

그래서 널개님께서 TCP 연결을 '착각'이라고 표현하셨는데, 이게 바로 이런 이유때문입니다.
TCP 연결은 착각입니다.

그리고 LAN 선을 뽑고 1초 후에 다시 꼽으면 파일 다운로드가 잠깐 중지되었다가, 다시 연결되어 진행된다고 합니다.
왜냐하면 L1에서 연결을 끊는 시도가 있었지만, L4 수준에서 TCP의 논리적인 연결이 지속되기 때문입니다.

그리고 네트워크에서 LAN이 뽑혀서 Host간의 연결이 끊어지는 것을 충격이라고 합니다.

그 충격이 발생했다 하더라도 서비스는 원활히 진행되어야 하기때문에 버퍼에 데이터를 조금 채워놓습니다.

영상이면 영상데이터를 채워놓습니다.
만약 5초정도 재생할 수 있는 분량이라면, 1초동안 재생하다가 4초가 남습니다.
그 데이터를 Buffer에 채워놓는데, 그 Buffer를 충격 완화 장치라고도 합니다.

네트워크에서 케이블이 끊기는 충격을 완화하기 위해 Buffer가 있습니다.

물론 유선에서는 LAN선을 넣었다 뺏다 하지않습니다.
그런데 이러한 현상이 무선의 경우에는 늘상 일어납니다.

지하철에서 와이파이라면 괜찮지만, 5G, LTE로 통신을 한다고 하면 중계기가 계속 떨어졌다 붙었다 하면서 충격이 나지만, 스트리밍이 계속 지속됩니다.
왜냐하면 중간에서 Buffer가 충격을 완화해주기 때문입니다.

(지금 PC로 널개님의 강의를 보고있다만, 지하철로 보다보면 LTE가 끊깁니다.. 아마 중계기(?)가 연관되있을 것이라는 것은 처음 알았습니다..)

2-29. TCP 연결과 게임버그

예를 들어서,
어떤 한 남성과 여성이 있다고 가정했을 때,
남성과 여성이 부부관계입니다.
남성이 여성에게 전화를 합니다.
그 받은 여성이 이 남성의 부인과 똑같은 목소리로 "여보세요~?"라고 한다면 이 남성은 자신의 부인이 받았다고 생각하겠지만, 실제로는 정말 부인일까요..?

아닐 수도 있습니다.

이런 것처럼 TCP연결은 착각에 불과하다고 말합니다.

위 그림에서 TCP연결을 위에 말한 관점에서 생각해보자면,
SYN을 통해서 연결을 하자고 한 것은 Client입니다.
그리고 Client는 SYN+ACK이 오면 TCP 연결이 이루어졌다고 믿습니다.

따라서 TCP의 연결과 더불어서 따라다니는 말이 보안성입니다.

보안의 3대 요소는 다음과 같습니다.

  • 기밀
  • 무결
  • 가용

기밀은 누가 도청할 수 있는가.
무결은 다른 놈이 흉내내는 것
나는 "아"라고 했는데 "어"라고 들리게 조작을 하여 변조한 것이 없다는 것을 보장하는 것입니다.)
가용은 항상 되게 해주는 것입니다.
(재해대책과 관련된 것이라고 합니다. 저도 모릅니다..)

TCP 연결에는 보안성에 관한 내용이 전부 없습니다.
그렇기 때문에 TCP연결을 너무 신뢰해서는 안 됩니다.

따라서, TCP 연결은 착각입니다!!

2-30. 한 번에 끝내는 DNS

만약 www.naver.com을 접속하기 위해서는 TCP/IP로 접속해야하고, IP를 알아야만 하는데,
IP는 어떻게 알 수 있는가..

DNS에서 알 수 있습니다.
분산 구조형 데이터베이스는 예~전에 114에서 전화해서 전화번호를 물어보던 것과 같습니다.

그리고 전화번호를 저장하고 난 후에, 저 같은 경우는 전화번호를 찾기보단 전화번호의 주인을 검색해서 전화를 겁니다.

DNS가 이와 같은 역할을 합니다.

DNS는 분산 구조형 데이터베이스와 트리(tree) 구조의 도메인 네임(Domain Name)체계로 되어있습니다.

먼저 도메인네임에 대해서 알아보자면,

'www.naver.com'이 있으면,
www는 naver에 속한 것이고,
naver는 com에 속한 것입니다.

우리나라와는 반대로 더 큰 개념이 뒤에 옵니다.

그리고 www.naver.com 중 naver.com이 Domain Name입니다.
그리고 www을 Host Name이라고 합니다.

이처럼 url 주소는 Domain Name과 Host Name이 따로 있습니다.
그럼 분산 구조형 데이터베이스는 무엇인가..

만약 A라는 사람에게 PC가 있고, 공유기를 통해서 ISP(Internet Service Provider)로 나가게되는데,
A라는 사람이 컴퓨터로 www.naver.com을 접속하력고합니다.

그럼 A가 이용중인 ISP 서비스에 따라서 DNS틀 통해서 Naver의 IP를 응답합니다.
그리고 받은 IP를 통해서 Naver에 접속하게 됩니다.

그리고 접속 중 시간이 걸리는 경우가 있을 수 있습니다.
예를 들면,
KT의 ISP를 이용하지만, 다른 ISP의 영역에 있는 구글의 DNS 주소인 8.8.8.8을 통해서 어떤 특정한 IP를 찾을 때 구글의 DNS가 거리가 있다면 접속 중 시간이 길어질 것입니다.

혹은,

naver.com는 멀쩡한데, DNS 서버가 이상이 있어서 접속이 느린 것처럼 보이는 경우가 있습니다.

그리고 DNS는 IP주소도 주긴하지만, 유효기간도 함께 응답해줍니다.

그리고 PC는 받은 Domain Name과 IP를 DNS Cache에 저장해둡니다.
그리고 다음부터는 서버 접속시 필요한 IP와 Domain Name을 ISP까지 가서 DNS에 물어보는 것이 아니라, DNS Cache에 있는지 확인하고 있으면 바로 접속하게 됩니다.

참고로 DNS Cache를 알 수 있는 명령어가 있습니다.
윈도우 기준이란 것 참고하시면 될 거 같습니다.

※ 참고 명령어
ipconfig /displaydns

공유기와 관련된 DNS 이야기

가끔씩 PC에서 DNS 주소가 공유기 주소일 경우가 있다고 하는데,
이 때 DNS 서버의 역할을 공유기가 하는 것이 아니라 공유기가 DNS서버로 포트 포워딩을 통해서 Domain Name을 얻어오는 경우가 있다고 합니다.

Root DNS

방금 ISP(KT, SK, LG 등)도 DNS서버가 있다고 하였는데, 사실 이 또한 DNS Cache 서버입니다.

그럼 이 DNS 서버들은 어디서 DNS를 질의해서 캐싱을 하느냐..

Root DNS를 통해서 얻어옵니다.

이는 전세계적으로 13대가 있다고 합니다.

Root DNS도 iana.org에 가시면 알 수 있고, 저 사이트에서도 DNS를 질의할 수 있습니다.
즉, Root DNS는 DNS 서버를 위한 DNS 서버입니다.
(메타 DNS??)

만약..
(정말 만약입니다. ISP에서 Naver가 없을리가...있을 수도 있겠네요..)
PC에서 www.naver.com을 질의하는데,
ISP의 DNS에서 찾을 수 없다면, ISP의 DNS는 Root DNS 서버로 Domain name을 질의합니다.

그런데, 먼저 www.naver.com을 찾는 것이 아니라,
com을 담당하는 DNS 목록을 알려줍니다.
(이 com을 담당하는 DNS 서버도 한 두대가 아닙니다.)

거기서 한 DNS 서버에 naver에 대한 Domain Name을 질의합니다.
그리고 응답받으면, naver의 DNS서버에서 www인 DNS를 찾습니다.

이 때 naver DNS는 www.naver.com에 대한 IP를 응답합니다.
그럼 ISP는 www.naver.com과 IP를 캐싱해놓고,

어떤 네트워크 영역에서 www.naver.com에 대한 질의가 올 때, 응답하여 알려줍니다.

2-31. 웹 기술 창시자와 대한민국 인터넷

이 분이 웹 기술 창시자 티모시(팀) 버너스리 슨상님입니다.

어떻게 입자물리연구소에서 HTML과 HTTP가 창시되었을까요..?

아무래도 연구소다보니 논문을 쓰게 되고, 맨 마지막에는 참고문헌이 각주로 달려있는 것을 흔히 아실 겁니다.

그리고 논문 참고를 생각하시면 꼬리에 꼬리를 무는 참고논문들이 많은 것을 흔히 아실 겁니다.

그런데 그 논문들을 연결하여 바로바로 확인할 수 있도록 하기 위한 고민을 하다보니 HTML이 창시되었다고 합니다.
(그냥 a태그인 거 같은데, 당시에는 혁명이었다고 합니다.)


참고로 **HTML의 본질**은 **문서**입니다.
그리고 **HTTP는 HTML을 실어나르기 위한 프로토콜**로 만들어졌습니다.
그리고 **HTTP를 사용하기 위한 인프라 스트럭처로 인터넷을 이용**했습니다.

이번 강의는 이 세 문장이 핵심입니다.

그리고 웃긴 것은 한국에 오셨을 때가 있었다고 하는데,
어떤 인터뷰어가 url 중 "http://~~" 에서 "빗금은 왜 있는 것이냐?" 라고 누가 물어봤다고 하는데,
슨상님께서 실수를 하셨다고 합니다...
아래는 참고 사진입니다

그리고 "전길남 박사님 얘기"...
이 분 덕에 한국이 IT 강국이 되었다고 널개님께서 말씀하시네요...ㅎ

박사님 덕에 우리나라에 네트워크가 처음 구축되었습니다.
(서울대학교와 경북 구미의 전자기술 연구소와의 연결)

그리고 당시 라우터가 군사 기술장비로 쓰여질 때였는데,
이 박사님께서 어떻게.. 독자적으로 구현하셨다고 합니다...

이처럼 IT강국이 된 이유엔 박사님의 노고와 수고가 있었고, 제자분들도 어마어마합니다....ㅎㅎ;;

2-32. URL과 URI

  • URL
    Uniform Resource Locator

  • URI
    Uniform Resource Identifier

URL은 URI의 범주 안에 포함됩니다.
식별자로 보는 것은 포괄적인 개념이고, 위치 URL을 말하게 되면, Resource(파일)의 위치까지 특정한다는 수준까지 말한다고 보시면 됩니다.

아래 그림을 보면,

보통은 이렇지만, 이 밑에 있는 userinfo`` 혹은@` 같은 것들은 잘 쓰지 않습니다.

이를 알아보기 쉽게 한 것이 아래 사진입니다.

위 에서 "www.test.co.kr"가 있는데 http(프로토콜)로부터 kr까지의 URL로 Host를 식별할 수 있습니다.

그리고 그 뒤("/")부터 경로 개념이 나오게 됩니다.

그리고! 보통 "http://test.co.kr"이 있다고 하면,
이 URL에 숨겨진 것이 있습니다.
많이들 아실겁니다.
바로 index.html입니다.

(참고로 스프링 얘기지만, 보통 view를 반환할 때 홈페이지로 기본적으로 렌더링되는 기본 페이지가 index.html이었는데 이게 이런 이유였군요..하하하)

URL, URI는 결국 중간 글자인 R에 해당하는 Resource 즉 자원을 접근하는데 중점을 두는 표현이 아닌가...생각됩니다.

URI의 문법

물음표(?)뒤로 나오는 것이 Parameter이고, Parameter에 값을 주기 위해서는 "="을 사용하여 value를 넘깁니다.
그리고 파라미터가 두 개 이상이면 '&'를 통해서 파라미터들을 이어줍니다.

ex) kr?cmd=search&search_keyword=Test
Parameter : cmd, search_keyword
Value : search, Test

2-33. 굵고 짧게 살펴보는 HTTP

HTTP

  • HTTP는 HTML 문서를 전송 받기 위해 만들어진 응용 프로그램 계층(L7) 통신 프로토콜입니다.
  • 1996년에 1.0 스펙이 발표됏으며, 1999년 6월에 1.1이 발표되었습니다.
  • 기본적으로 클라이언트의 요청에 대응하는 응답형식으로 작동합니다.
  • 헤더는 다음과 같이 분류됩니다.
    • 일반 헤더
    • 요청 헤더
    • 응답 헤더
    • 엔티티 헤더
  • 요청에 사용되는 메서드는 주로 GET, POST입니다.

응용 프로그램 계층 즉 L7 계층인데, 이전 챕터부터 보면 L5 이상부터는 Socket통신을 한다고 했었고, Socket통신은 Stream 데이터라고 했는데,
Stream 데이터는 시작은 확실하지만, 끝이 언제인지는 해석해봐야 알 수 있습니다.
그 규정이 HTTP에서는 HTTP(프로토콜)에 약속되어있습니다.
신기한 것은 보통의 경우 프로토콜에서 IP나 TCP를 봤을 때 16진수로 표현되어있지만,
HTTP는 문자열로 되어있습니다.
(Header부분도 문자열로 되어있습니다.)

HTTP의 핵심은 요청하고, 응답하는 것입니다.
(본질적으로는 HTML(문서)를 요청하고, HTML을 응답하는 것입니다.)

위 그림은 네트워크 프로그램인 Wireshark로 살펴본 네트워크의 Header입니다.
빨간 부분은 요청에 대한 정보입니다.
어떤 메서드인지, HTTP버전은 어떠한지, 소프트웨어 정보(모질라 5.0..)은 무엇인지, 어떤 형식인지, 인코딩 정보 등등 많은 정보들이 있습니다.

그리고 그 밑은 파란부분은 응답에 대한 정보입니다.

다음 사진은 HTTP 응답코드입니다.

설명은 생략하겠습니다.
(사실 딱히 없습니다.)

위 그림은 HTTP 메서드에 어떤 것이 있는지를 보여줍니다.
이 부분도 설명은 생략하겠습니다.
(역시 사실 딱히 없습니다..)

이 부분은 개인적으로 김영한님의 HTTP 강의가 조금 더 자세한 거 같습니다...^^;;

HTTP 강의 정리 링크입니다!

2-34. 그림 한 장으로 외워서 끝내는 웹 서비스 구조 기본이론

참고로 이 그림은 거대해집니다..

네트워크와 같은 인프라 스트럭처에 대한 공부를 할 때 중요한 것은 구조를 이해하는 것입니다.
(인프라 스트럭처의 스트럭처가 구조라는 의미긴 하네요..ㅎㅎ)

클라이언트와 서버 간에는 TCP/IP를 기반으로 HTTP 통신이 이루어지는데,
TCP/IP는 연결을 지향하지만, HTTP는 stateless, 즉 상태를 저장하지 않습니다.

클라이언트에서 서버로 Resource를 요청하는데,
URL과 매핑된 IP를 DNS를 통해서 물어보고,
IP주소를 접속한 다음,
TCP 연결을 실시하고,
그 TCP/IP 연결을 기반으로 HTTP 통신이 이루어집니다.

HTTP 통신이 이루어지는 시점에서 http.request의 메서드로 GET 메서드를 사용합니다.
그럼 클라이언트에서는 응답으로 오는 HTML을 브라우저를 통해서 보여줍니다.

※참고.
강의 중 개발시 설계원칙에 대해서 언급하시는데,
UI , Data(자료구조), 제어(컨트롤러->비즈니스 로직)을 분리시키는 것이 원칙인데,
결국 좋은 설계원칙은 유지 보수의 용이성에 있다고 합니다.
UI/Data/제어가 같이 있는 것이 아니라, 모듈로 분리해서 관리하는 것이 좋습니다.

그리고 HTML문서 그 자체를 브라우저에 표시하게 되는 것도 좋았지만, HTML문서를 꾸미는 문법 또한 등장하게 됩니다.
이 HTML문서를 꾸미기 위한 것이 바로 CSS입니다.

그리고 1990년대 중반에 정적인 HTML문서를 동적으로 반영하려고 하는 시도가 나왔습니다.
그리고 동적인 움직임에는 규칙이 있기 마련이고, 그 규칙이 스크립트 형태로 등장하게 되는데, 처음 등장한 것이 모카 스크립트(Mocha Script)입니다.

이 모카 스크립트가 몇달 후 명칭을 바꾸게 되는데 라이브 스크립트(Live Script)로 바꿉니다.
그리고 또 몇달 후, 라이브 스크립트도 명칭을 바꾸게 되는데, 그 바뀐 스크립트가 현재 잘 사용되고 있는 자바스크립트입니다..!!

이처럼 HTML, CSS, JS가 같이 모인 형태가 오늘날의 웹의 기본 구성 요소가 됩니다.

HTTP의 요청에 대해 HTML, CSS, JS가 같이 호환되면서 HTTP의 응답을 하게됩니다.

처음의 웹은 지금처럼 사용자가 개입하는 형태로까지 발전한 상태는 아니었습니다.
클라이언트가 단순히 요청하고 응답받고, 요청하고 응답받고만 하는 단방향으로만 활용되었습니다.
즉, 논문을 쉽게 볼 수 있는 인프라가 갖춰졌지만, 사용자가 개입하는 형태로는 발전하지 못했던 것이죠.

GET메서드로는 단순한 요청,응답으로 단방향으로만 작용했지만,
POST메서드가 등장하면서 양방향으로 상호작용하게 되었습니다.

그런데, 양방향 상호작용에 반드시 따르게 되는 것이 있습니다.
작용의 절차를 따르는 문맥
문맥이라고 표현하셨지만, 맥락이 더 어울리는 거 같습니다..? 제 국어관점에서는...
즉 상태 전이가 반드시 필요합니다
만, HTTP는 Stateless입니다.

그래서 상태를 기억하도록 해야하는데,,,
클라이언트도, 서버도 상태를 기억하도록 해야합니다.

그 기억을 구현한 것이 클라이언트에서는 Cookie입니다.
Cookie는 상호작용을 위한 기억의 부산물로 생각하면 됩니다.(자세히 알고싶으면 영한님 강의 보세요^^)

서버에서는 기억해야될 것이 너~무나 많습니다.
서버에서는 기억을 구현한 것이 바로 Database입니다.

사용자가 클라이언트에서 ID,PASSWORD를 입력하고, 서버로 데이터를 보내게되면,
서버는 클라이언트로부터 받은 ID, PASSWORD로 Database에 질의를 합니다.

그런데 서버가 Database로 바로 접근하는 것이 아니라, 웹서버와 Database의 중간에서 중계해주는 역할을 하는 것이 있습니다.

웹서버의 역할은 송/수신을 담당하는데, 리소스를 보내고 받는 역할을 합니다.
데이터베이스는 자료의 기억을 담당합니다.

그리고, 중간에서 중계해주는 서버가 있다고 하였는데, 그것은 연산에 대한 처리를 담당합니다.
(이 중간의 서버가 WAS를 가리키고 있습니다.)

다시 돌아가서 웹서버는 ID, PASSWORD를 데이터베이스와 웹서버 사이의 중계 서버로 데이터를 보냅니다.

그리고 받은 데이터와 데이터베이스에 질의한 데이터를 가지고, 동적으로 새로운 HTML문서를 만들어서 보내줍니다.

('동적'이란 말 나왔습니다 끝났습니다. 그냥 이건 WAS입니다.. 다음 챕터에 나올 거 같습니다.)

2-35. WAS와 RESTful API 그리고 JVM

웹 서비스의 기본구조는
웹서버 - WAS - Database입니다.
그런데 이 한 요소를 1-Tier라고 하는데,
총 3개의 Tier가 모여서 3-Tier의 모양을 갖추게 됩니다.
(물론 웹서버와 WAS를 합칠 수 있긴합니다.)

중요한 것은
네트워크가 빨라도, 처리가 안 되거나, DB 질의가 느려 응답이 느려지는 경우가 있는데,
요청에 대한 응답시간은 서비스의 품질을 확인하는데 굉장히 중대한 역할을 합니다.

그래서 WAS와 DB를 모니터링해서 웹 어플리케이션의 상태를 관리하는 시스템이 있는데, 이를
APM(Application Performance Management)이라고 합니다.

관련 오픈소스에는 Scouter가 있습니다.
(자바로 된 오픈 소스입니다. 실제 써봤었던 기억이...)

널개님이 자주 그리는 내용이 있습니다.
이 강의에도 있습니다.

H/W 위에 Kernel, 그 위에 User Mode 등
다음과 같은 그림입니다.

User Mode에서 어플리케이션 수준에 CPU를 구현했는데, 이를 S/W 형태로 구현했는데,
Java 기반의 CPU, S/W이므로, Virtual, 기계이기 때문에 Machine 이라고 하여
JVM이 이루어졌습니다.

JVM은 Java를 위해서 소프트웨어로 구현된 CPU입니다.

그런데 JVM이 인식할 수 있는 명령체계가 있는데, 그 명령체계가 bytecode입니다.

결국 연산하는 것은 bytecode입니다.

이 Java bytecode를 기반으로 어플리케이션을 작동시켜주는 것이 있는데, 이를 Middleware라고 합니다.

Middleware는 소프트웨어인데, 다른 소프트웨어가 작동할 수 있도록 도와주는 소프트웨어입니다.

이 이후에는 자바의 JSP를 예시로 들며
요청에의한 응답으로 HTML, CSS.JS, WAS에 의해 생성되는 JSP가 응답되는 과정을 설명해주십니다.
그리고 CRUD, API, SSL.. 등등

그냥 웹서비스의 전체적인 기본구조에 대해서 하나하나 다 언급하십니다...^^

3. 요약

지금까지 출퇴근 + 개인적인 출퇴근 이전, 이후의 시간에 들은 네트워크에 대한 강의를 정리했습니다.

다음 과목은 운영체제입니다만, 강의 정리는 따로 안 하고, 책에 바로바로 필기하면서 공부해나갈 예정이기 때문에, 블로깅은 따로 안 할 예정입니다.

이번 강의는 두서 없이 쓴 부분도 있지만, 네트워크에 대해서 알고자하는 분에게 도움이 되길 바라며 포스팅합니다!

참고로 다음으로 진행할 운영체제는 널널한 개발자님의 곰책으로 시작하는 운영체제 강의이고, 책은 곰책이 절판되어 2판으로 나왔는데, 진행상 문제는 없다고 하셨습니다.

728x90
저작자표시

'CS > 네트워크' 카테고리의 다른 글

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런(김영한)  (0) 2023.09.19
'CS/네트워크' Related Articles more
Comments