CS 스터디 - 네트워크 이론

OSI 7계층 & TCP / IP 4계층 모델

 

https://devowen.com/344#OSI%207계층%20모델-1

OSI 7 계층 ? TCP / IP 4계층 ? 

[ OSI 7계층 ]
- 네트워크 통신이 일어나는 과정을 7단계로 나눈 것 
- 통신이 일어나는 과정을 단계별로 파악하기 용이
[ TCP / IP 4계층 ]
- 네트워크 전송 시 데이터 표준을 정리한 것이 OSI 7계층이라면, 이 이론을 실제로 사용하는 표준이 TCP/IP 4계층
 

응용 계층 

- 응용 프로세스와 직접 관계하여 응용서비스 수행하는 최종 목적지
- 사용자에게 통신을 위한 서비스 제공
- HTTP : Word Wide Web 위한 데이터 통신의 기초이자 웹 사이트 이용하는데 쓰이는 프로토콜
- FTP : 장치와 장치 간의 파일을 전송하는데 사용되는 표준 통신 프로토콜 
- SMTP : 전자메일 전송을 위한 인터넷 표준 통신 프로토콜
- DNS : 도메인 이름과 IP 주소 매핑해주는 서버, DNS 덕분에 IP 주소가 바뀌어도 사용자에게 똑같은 도메인 주소로 서비스 가능
 

표현 계층 

- 데이터의 형식을 정의, 코드 간의 번역 담당
- 파일 인코딩, 명령어를 포장/압축/암호화 하는 등의 역할 수행
 

세션 계층 

- 컴퓨터끼리 통신을 하기 위해 TCP/ IP 세션 만들고 없애는 계층
- 세션 설정, 유지, 종료, 전송 중단시 복구를 담당하는 등의 기능
- 데이터가 통신을 하기 위한 논리적 연결 담당
 

전송계층 

- 통신을 활성화하기 위한 계층, 데이터의 전송을 담당. 
- TCP : 신뢰성, 연결지향적 (가상회선방식)
* ) 3-way handshaking 과정을 통해 연결 설정, 높은 신뢰성 보
패킷 전송 순서 또한 보장되며, 단점으로는 속도가 느림
가상 회선 방식을 통해 통신한다 (발신지 - 수신지 사이 패킷을 전송하기 위한 논리적 경로 배정
 
- UDP : 비신뢰성, 비연결성, 실시간
* ) 연결을 위해 할당되는 경로 없이, 각각의 패킷이 다른 경로로 전송된다 -> 데이터 전송 순서 바뀔수있음
1 : 1 뿐만 아니라 1 : N & N : N 통신도 가능. 
흐름제어 안하기 때문에 제대로 전송이 되었고 데이터에 오류가 없는지 확인하지 않는다 (막 보낸다고 생각)
대신 신뢰도가 떨어지므로 신뢰성보다 연속성있는 전송이 필요할 때 사용한다 (스트리밍 등)
 
 

네트워크 계층 

- 패킷을 목적지까지 가장 빠른 길로 전송하기 위한 계층 
- 라우터를 통해 이동할 경로를 선택하여 IP주소 지정하고, 해당 경로따라 패킷 전달
- 데이터를 연결된 다른 네트워크를 통해 전달 ~ 인터넷이 가능하게 만든다. 
- IP 주소를 사용. 
 

데이터링크 계층

- 데이터의 물리적인 전송, 에러 검출, 흐름 제어 담당
- 물리 계층으로 송수신 되는 정보를 관리하여 안전하게 전달되도록 돕는다. 
- MAC 주소 사용하여 통신 
* ) MAC 주소 : 네트워크 통신을 하는 하드웨어에 할당된 주소. 컴퓨터나 노트북 등의 장치에는 네트워크에 연결하기 위한 장치(LAN카드)가 있는데 이를 구별하기 위한 식별 번호를 뜻한다. 

https://crazykim2.tistory.com/746

 
* ) IP -> MAC 변환하는 과정을 ARP(Address Resolution Protocol)라고 한다
 

물리계층 

- 데이터를 전기 신호로 변환하고 주고받는 계층
- 리피터, 케이블, 허브 등
 

---

http 프로토콜 특징

- connectionless : 비연결지향
*) 클라이언트가 서버에 요청했을 때 응답을 보낸 후 연결을 끊는 처리방식
*** ) HTTP 1.1 버전에서 커넥션 계속 유지하고, 요청에 재활용하는 기능이 추가되었음(keep-alive 옵션이 디폴트)
*** ) HTTP가 TCP 위에서 구현되어서 연결지향적이 아닌가? -> 네트워크 관점에서 keep-alive는 옵션으로 두고, 서버 측에서 비연결지향적인 특성으로 커넥션 관리에 대해 비용을 줄이는게 명확한 장점으로 보기 때문에 비연결 지향으로 많이 작성
- stateless : 커넥션을 끊는 순간 클라이언트의 상태 정보는 유지하지 않음
 
쿠키 & 세션, 그리고 jwt 토큰? 
HTTP 통신은 statless하기 때문에 서버가 응답을 완료하면 연결을 끊음
-> 클라이언트가 누구인지 알 수 없다. 누가 로그인 중인지 알아야 하는 등 클라이언트의 상태를 기억하기 위해 등장. 
 
[ 🍪 쿠키 ]
서버가 클라이언트의 요청에 대해 응답을 보낼 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 set-cookie에 담는다.
이후 클라이언트는 서버에 재요청할 때마다 저장된 쿠키를 요청 헤더의 cookie에 담아 보낸다. 
-> 서버는 쿠키에 담긴 정보를 바탕으로 요청의 클라이언트 누구인지 식별 가능
 
[ 세션 ]
클라이언트가 서버에 요청한 시점부터 종료하여 연결 끝내는 시점까지 같은 클라이언트로부터 들어오는 요청들을 하나의 상태로 보고 , 그 상태를 유지시키는 기술.
- 각 클라이언트에 고유 session ID를 부여하고 이를 통해 클라이언트 구분한다. 
- session id 생성해서 클라이언트에게 넘겨주고, 클라이언트는 이를 쿠키에 저장, 서버에 요청시 session id 값 같이 저장, 서버는 session id토대로  session에 있는 클라이언트 정보를 기반으로 요청에 응답
 

* 세션도 결국 쿠키를 사용하기 때문에 역할, 동작 원리가 거의 비슷하다.  차이점이라면 정보가 저장되는 위치, 라이프사이클이다. 

쿠키 : 서버의 자원 사용 X, 클라이언트 로컬에 저장된다. 
-> 변질되거나 탈취 가능성 있지만 속도가 빠름(쿠키에 정보가 있으므로)
-> 클라이언트 로컬에 파일로 저장되므로 브라우저 종료해도 정보가 유지된다. 만료기간 따로 지정도 가능 
세션 : 쿠키 활용해서 session-id만 클라이언트 측에, 나머지 정보들은 서버에 저장
->  보안이 우수하나(세션id털려도 서버측에서 삭제하는 등 무효처리하면 된다)  속도가 느림
-> 세션도 만료기간은 지정할 수 있지만 이와 상관없이 브라우저 종료되면 삭제된다
 
[ JWT 토큰 ]
JSON 포캣을 사용하는 Claim 기반의 웹 토큰, 토큰 자체를 정보로 사용하는 self-contained 방식
헤더(토큰 타입, 해시 암호화 알고리즘), 내용(Claim, JSON 형태의 쌍), 서명(토큰을 인코딩하거나 유효성 검증할 때 사용하는 고유한 암호화 코드)으로 구성되며 각 파트를 . 으로 구분
- 클라이언트가 서버로 요청할 때 토큰을 헤더에 실어서 보낸다. 
 
* ) claim : 토큰에 담는 정보의 한 '조각'을 의미, jwt ~ token parse할 때 아마 사용해봤을 듯
클레임 종류는 registered / public / private 3종류
우리가 주로 프로젝트에서 사용하는건 private(클라이언트 - 서버 간 합의 하에 사용되는)

https://velog.io/@dnjscksdn98/JWT-JSON-Web-Token-소개-및-구조

쿠키&세션과 비교 

- 쿠키&세션(서버 기반 인증시스템)처럼 저장소의 관리가 필요하지 않다. (토큰 자체가 인증에 필요한 정보 담고 있으므로) : 따라서 statelss하다. 
- 확장성이 뛰어남. REST 서비스로 제공 가능
- 대신 토큰 길이가 길어서 저장하는 정보가 늘어날수록 네트워크 부하
- 토큰 탈취당하면 만료 시간까지는 계속 활용이 가능(쿠키&세션은 그냥 지워버리면 되는데 얘는 만료될때까지 기다려야함)
 
결론 
일반적으로 웹 어플리케이션의 서버 확장 : 수평확장(scale out - 여러대의 서버 추가 설치) 방식, 여러 대의 서버가 요청을 처리한다. 
이때 별도의 작업을 하지 않으면 다중 서버환경에서의 세션 불일치 문제(CORS) 발생.. (여러 부가적인 작업 필요)
하지만 토큰 방식의 경우 서버가 직접 인증방식을 저장하지 않고 클라이언트가 저장하므로 이런 문제로부터 자유롭다(확장성 좋음)
보통은 단일 도메인일 때 좀 더 세션 방식이 적합, 그외에는 토큰 기반이 적합하다고 보임. 
추가로, 서버의 부담 측면에서도 상대적으로 토큰이 유리. 
 

---

 

LoadBalancing? 

여러 요청들에 대한 모든 트래픽을 감당하기엔 1대의 서버로는 부족
- 수직확장 : 하드웨어의 성능을 올리자! (Scale-up)
- 수평확장 : 여러대의 서버가 나눠서 일하도록 하자! (Scale-out)
하드웨어 향상 비용이 더욱 비싸기도 하고, 서버가 여러대면 무중단 서비스를 제공하는 환경 구성이 용이하므로 Scale-out이 더 효과적이다. 이때 여러 서버에게 균등하게 트래픽을 분산시켜주는 것이 바로 로드 밸런싱이다.
 

어떻게 트래픽을 분배하는가? 

 
- RoundRobin :  요청 온 순서대로 각 서버에 배분하는 방식 , 각 서버에 가중치를 부여하는 가중 라운드 로빈 방식도 존재 
- Least Connections : 연결 개수가 가장 적은 서버 선택(각 서버에 대한 현재 연결 수를 동적으로 카운트, 분산) 
- Least Response Time Method : 서버의 현재 연결 상태와 응답 시간을 모두 고려, 가장 적은 연결 상태와 가장 짧은 응답 시간을 보이는 서버에 우선적으로 로드를 배분하는 방식이다.
- IP 해시 방식 : 사용자 IP Hashing해서 분배 (특정 사용자가 항상 같은 서버로 연결되도록) 

---

Proxy? 

-> 두 PC가 통신을 할 때 직접 하지 않고 중간에서 대리로 통신을 하는 것을 의미.
-> 프록시 서버는 클라이언트와 서버 사이의 ‘중계 서버’ 
-> 보안 목적이나 캐싱 등의 기능으로 사용. 
프록시 서버가 중간에 위치함으로써 클라이언트는 프록시 서버를 ‘서버’라고 인식하고, 서버 입장에서는 프록시 서버를 ‘클라이언트’로 인식하게 된다.
 

포워드 프록시(일반적으로 프록시라고 하면 이것을 의미) 

클라이언트에서 서버로 리소스를 요청할 때 직접 요청하지 않고 프록시 서버를 거쳐서 요청
클라이언트 - 프록시서버 - 인터넷 - 서버 이런 느낌

• 캐싱 : 정적 데이터 저장해두고 동일 요청인 경우 웹서버까지 가지 않음 
• IP 우회 : 서버 측은 클라이언트의 IP가 아닌 프록시 서버의 IP를 전달받음. 
• 사내망 : 정해진 사이트에만 연결할 수 있도록 설정 

 

리버스 프록시 (nginx, apache web server)

애플리케이션 서버의 앞에 위치하여 클라이언트가 서버를 요청할 때 리버스 프록시를 호출하고, 리버스 프록시가 서버로부터 응답을 전달받아 다시 클라이언트에게 전송하는 역할
클라이언트 - 인터넷 - 리버스프록시 - 서버 

• 로드밸런싱 : 리버스 프록시 뒤에 여러 개의 was를 둠으로써 사용자 요청을 분산, 엔드포인트마다 호출 서버를 설정할 수 있어 역할에 따라 서버 트래픽 분산 가능
• 보안 : 서버에 직접 접근하는 것을 막기 위해 dmz 같은 네트워크에 리버스 프록시 구성하여 접근

+) dmz : 조직의 내부-외부네트워크 사이 위치한 서브넷, 내부와 외부가 dmz로 연결할 수 있도록 허용하면서도, dmz 내부 컴퓨터들은 외부에서만 연결 가능하다(dmz내 호스트들은 내부로 연결 불가능)
 

---

CDN? 

- 콘텐츠 전송 네트워크
- 사용자와 가까운 곳에 데이터 서버를 배포하여 트래픽이 많은 웹 사이트가 빨리 표시되고 동영상 스트리밍 서비스가 신속히 제공되도록 지원하는 역할 
- 이미지, 비디오 등의 컨텐츠를 사용자의 물리적 위치와 가까운 프록시 서버에 캐싱, 콘텐츠가 로딩될 때까지 기다릴 필요 없이 영화 감상, 소프트웨어 다운로드, 은행 잔고 확인, 소셜 미디어 포스팅, 구매 등의 작업 가능하다.
- 지연 시간을 줄이는 목적으로 사용, 광범위하고 넓게 cdn이 분산되어 있을수록 웹 콘텐츠 보다 빠르고 안정적으로 전송 가능 

---

WebSocket 

웹 소켓(Web Socket) :  하나의 TCP 접속에 전이중(full-duplex) 통신 채널을 제공하는 컴퓨터 통신 프로토콜이다. tcp에 의존하지만, http에 기반하므로 7계층소속, 메시지 형식의 데이터를 다룸. 
-> 서버와 브라우저 사이 양방향 통신이 가능하게 만든다. 클라이언트의 요청이 없다면 서버로부터 응답을 받을 수 없던 문제를 해결하기 위해 등장하였다. (ex 실시간 데이터 받으려면 새로고침 계속 눌러줘야 한다던가) 
소켓(Socket) : 네트워크상에서 동작하는 프로그램 간 통신의 종착점. 대부분의 통신은 인터넷 프로토콜(TCP, UDP)에 기반하고 있으므로 대부분의 네트워크 소켓은 인터넷 소켓이다. 바이트로 이루어진 데이터를 다룬다.
 
웹 상에서도 TCP 소켓 통신으로 실시간 통신을 할 수는 있지만 전송 계층의 원시 바이트 대신 애플리케이션 계층을 통해 메시지를 보내는 것이 개발측면에서 더 적합함. 둘이 완전 다르다기보다는, 웹 어플리케이션에 맞게 발전한 형태로 웹 소켓 통신을 한다고 이해. 

---

 
주소창에 www.naver.com  쳤을 때 생기는 일? 

https://develaniper-devpage.tistory.com/88

 
1. www.naver.com  은 도메인 네임이므로, 브라우저는 DNS에 도메인 검색을 위한 요청을 보낸다. 
2. DNS가 대응하는 ip 주소를 응답으로 돌려준다.
3. 받은 ip 주소를 사용하여 해당 ip 서버에 요청 보냄
4. 요청 받은 네이버 서버는 요청 내용에 대한 응답을 만든다.
5. 응답을 클라이언트 측에 전달
6. 브라우저(클라이언트)는 받은 응답메시지 기반으로 웹 페이지 구성하여 사용자에게 보여준다. 
 
 
 
참고한 블로그 및 자료

https://gyoogle.dev/blog/computer-science/network/OSI%207계층.html

https://devowen.com/344#OSI%207계층%20모델-1

https://tecoble.techcourse.co.kr/post/2021-11-07-load-balancing/

https://dev-coco.tistory.com/161

https://hudi.blog/session-based-auth-vs-token-based-auth/

https://velog.io/@jung5318/쿠키-세션-토큰의-차이점