728x90

CGI 란

서버와 애플리케이션 간에 데이터를 주고받는 이 프로세스 또는 규칙을 공통 게이트웨이 인터페이스(CGI)라고 한다. 동적인 컨텐츠를 생성할 수 있는 프로그램을 갈망하는 사람들의 요구로 인해 만들어진 규약이다.

 

 

CGI 작동 방식

프로세스기반으로 동작한다. 즉 매 요청마다 프로세스를 새로 시작하는 방식이다.

이로 인해 요청 수가 많아 지면 서버에 많은 프로세스가 생성되고,요청을 처리 후 종료 된다. 그래서 요청 수가 많아지면 서버에 부담을 준다.

 

FastCGI 의 탄생

이를 보완하기 위해 FastCGI와 같은 대안이 나왔다.

개선점은 매 요청 프로세스를 생성하지 않고 프로세스를 재사용할 수 있게 했다.

그래서 FastCGI 부터는 프로세스 풀이 생김.

IPC 최적화로 인해 멀티스레드와 멀티프로세스 지원이 가능해짐

 

 

결과적으로, FastCGI의 프로세스 풀 개념은 CGI가 겪던 성능 문제를 크게 개선해주었다. 이후의 다른 웹 애플리케이션 인터페이스들이 이러한 개념을 적용하면서 더 발전하게 됨.

 

 

참고

- https://kldp.org/node/73386

 

흠....PHP도 CGI 인가요? | KLDP

제가 CGI에 대한 정의들을 찾아보니 CGI란 클라이언트의 요청을 서버에서 받아 그 요청을 다른 응용 프로그램으로 넘겨서 필요에 따라서 그 결과를 다시 서버로 보내 서버에서 클라이언트로 그결

kldp.org

- https://jongminlee0.github.io/2020/10/10/cgivsservlet/

 

[Server] CGI와 Servlet에 대해서 - Jongmin's Blog

기존 Java를 이용하여 개발하고 현재는 PHP를 사용하여 업무를 하고 있습니다. 그렇다보니 두 언어의 차이점이 존재하고 그 차이점에 대해 궁금하였습니다. 그 중 PHP의 Fast-CGI를 맞닥드렸습니다.

JongMinLee0.github.io

- https://www.geeksforgeeks.org/difference-between-java-servlet-and-cgi/

 

Difference between Java Servlet and CGI - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

www.geeksforgeeks.org

- https://www.javatpoint.com/difference-between-java-servlets-and-cgi

728x90

connection에는 두 가지 종류가 있다.

1) connectionless 비연결형 서비스

2) connection oriented service 연결 지향 하는 서비스 이다. 이 두개의 차이는 데이터 전송을 할 때 connectionless 하는 프로토콜은 연결설정 같은거를 하지 않고 바로 데이터 전송을 한다. 반면 connection oriented service 는 연결 설정을 하고 데이터 전송을 하고 연결 해제를 하는 3단계 절차를 거친다.

 

그래서 connectionless는 자신이 전송할 데이터가 있으면 바로 segment(packet)을 만들어서 바로 전송해버리는 것이다. 이런 방식을 취할 때 역다중화가 어떻게 처리되는지를 살펴보려고 한다.

 

소켓을 만들 때는 host-local port를 지정한다. 이것은 호스트 내부에서 사용하는 port넘버이다.  포트넘버는 주소역할을 하는 것이기 때문에 겹치면 안됨. 그리고 데이터그램을 UDP socket을 통해서 보낼 때 destination IP address와 destination port number를 꼭 써서 보내야 한다. 안그러면 목적지 호스트 까지 찾아갈 수 없고, destination 호스트에 도착을 해도 해당하는 소켓까지 전달이 되지 않기 때문이다. 

 

호스트가 UDP segment를 수신하게 되면 segment에 있는 destination port number를 체크하게 된다. 그리고 해당하는 UDP segment를 해당하는 포트 넘버를 가진 소켓에다가 전달하게 된다. 그래서 이걸 정리를 해보면 동일한 source IP address(소스 아이피 주소)나 source port number(소스 포트넘버)와는 다른 destination port number를 가진 IP datagram는 목적지에서 동일한 소켓으로 전달이 된다. 다시 얘기하면 동일한  destination port number를 갖지만 서로다른 source IP address(소스 아이피 주소)나 source port number(소스 포트넘버)를 갖는 IP datagram이라면 모두 다 destination에서 동일한 소켓으로 전달이 된다는 것이다. 즉 source IP address(소스 아이피 주소)나 source port number(소스 포트넘버)는 구분자가 아니라는 얘기이다. 여기서 구분자는 destination port number와 destination IP address가 된다. 그러면 같은 소켓의 destination에 전달이 된다. 

 

demultiplexing( 다중화)에서 구분자는 destination port number destination IP address이다. 두개만 같으면 동일한 소켓으로 전달이 되게 된다. (source IP address(소스 아이피 주소) source port number(소스 포트넘버)와는 상관없이)

728x90

 

 

 

호스트는 IP 데이터그램을 수신하게 된다. 각 데이터그램에는 source IP address, destination IP address가 있다. 그리고 각 데이터그램은 한개의 트렌스포트 레이어 segment를 운반하고 있다. 즉 데이터 필드에 담아서 오게 되는 것이다. segment는 위의 그림입니다. 그리고 각 segment에는 source와 destination port number를 갖고있다. 

호스트는 IP address port number 사용해서 segment 적절한 소켓으로 전달하게 된다. 작업을 역다중화 라고 부른다. 얘기는 역다중화를 IP address port number 구분자 구실을 하는 것이다. 그래서 IP address port number 따라서 전달되는 소켓이 달라지는 얘기이다. 

728x90

 

multiplexing은 다중화 라고 한다. 다중화는 여러 흐름이 있을 때 그 흐름들을 하나의 묶음으로 처리 해주는 것이 다중화이다.

demultiplexing은 역다중화라고 한다. 역다중화는 하나의 흐름으로 묶여서 multiplexing해서 온 흐름을 다시 나누어 주는 것이 역다중화이다.

 

그러면 컴퓨터네트워크에서 얘기하는 다중화와 역다중화가 프로토콜에서는 어떤 의미를 갖는지 알아볼 것이다. 

 

먼저 각각의 호스트에 어플리케이션 레이어가 있다. 어플리케이션과 스렌스포트 레이어 사이에 있는 것은 “문”역할을 하는 소켓이다. 어플리케이션 안에 있는 하늘색 동그란 것들이 프로세스인데, 이 프로세스가 트렌스포트 레이어에 있는 프로토콜로 통신을 할 때 통로 역할을 하는 것이 소켓이다. 그래서 어플리케이션 프로세스는 소켓에 메시지를 전달하고 소켓을 통해서 트렌스포트 레이어에 있는 프로토콜은 메시지를 전달받아서 segment로 만드는 작업을 하게된다.  위 그림은 P1,2,3,4 다 서로 통신을 하고 있는 그림이다. 

다중화가 어디서 일어나나면,  p1와 p2 각각 가지고 있는 소켓으로 부터 나온 흐름이 오른쪽 왼쪽으로 처리해준다.(그림상으로), 트렌스포트 레이어(중간에 있는 빨간 동그라미)에서 처리해주는 프로토콜이 동일한 프로토콜이면 다중화가 이루어졌다고 얘기한다.  왜냐하면 두개의 흐름으로 하나의 흐름으로 처리가 되기 때문이다.  그래서 보내는 사람(sender)입장에서 다중화가 일어나게 되는데 multiple socket을 다루는 것이고 여기에 트렌스포트 헤더를 붙여준다. 즉 encapsulation 하는 것이다.

그림을 보면, P1, P2는 자기가 사용하는 소켓을 통해서 트렌스포트 레이어로 내려졌고 여기 레이어에 있는 프로토콜에서 트렌스포트 헤더를 붙여서 하나의 흐름으로 만드는 것이다. 이렇게 처리하는 것이 다중화이다. 

 

역다중화는 P3 P4 응답을 해서 segment 전송을 해준다. 그렇게 되면 트렌스포트 레이어에 있는 프로토콜에 두개가 도착하고 각각 P1 P2에게 나눠주게 된다. 헤더에 있는 정보를 사용해서 수신된 segment 적절한 소켓에다가 분배해주는 것이 송신자 입장에서 역다중화가 일어났다 라고 한다.

728x90

인터넷 구조에 대해 살펴보면 네트워크들에 네트워크이다.

 

access ISPs를 통해 end systems(단말, host)를 연결 할 수 있다.    *access ISPs에는 reesidential, company, university ISPs가 있다.

 

이제 access ISPs에 end system을 연결했으면 access ISPs들을 상호 연결을 해야한다. 그렇게 해야지만 서로다른 access ISPs에 있는 어느 두개의 호스트들이라도 각각에 패킷을 전송할 수 있게된다. 그래서 묶어줘야 한다. 그렇게 되면 네트워크가 복잡한 형태를 띄게 된다. 그래서 네트워크에 네트워크 발전은 경제 상황이라든가 국가정책에 의해서 개선이 된다.

 

계속 인터넷 구조를 살펴보자 (다음으로)

 

 

첫번째로 각 엑세스 아이에스피를 나머지 엑세스 아이에스피에게 전부 다 연결하는 방법이다.

 

규모를 키웠다 줄였다 하는게 원활하지가 않다. 왜냐하면 O(N^2)의 연결이 필요로 하여 많은 연결이 필요하기 때문이다. 게다가 access ISPs 하나가 추가되면 또 다 연결해야하기 때문이다.

 

각 엑세스 아이에스피를 하나의 글로벌 ISP에 access net을 연결해주는 것이다. 그러면 원활하게 묶을 수가 있다. 

문제는 Customer ISP와 provide ISP간의 경제적 동의가 있어야 하는점이다.

만약 하나의 글로벌 아이에스피가 독립적으로 비지니스를 운영하면 금방 경쟁자들이 발생하게 된다. 그러면 이러한 경쟁자들을 또 묶어줘야 한다. 그렇게 되면 글로벌 아이에스피 간에 peering link를 만들던가 아니면 internet exchange point를 제3의 조직이 만들어가지고 각각의 ISP들이 연결 가능한 기기들을 삽입해 각각을 연결해야한다.

 

각 지역별로 묶어 글로벌 아이에스피로 뿌려주는 것도 있다.

 

그리고 자기 자신의 네트워크를 운영하는 content provide network 같은것들도 운영되고있다.

 

인터넷 구조를 정리해보면 이러한 모양이 된다.

 

Tier 1 ISP는 글로벌 아이에스피가 표현되고 구글로 표현된 것이 content provider network를 표현된다. 그다음에 IXP는 Internet Exchange Point라고 해서 제3의 사업자 또는 공공기관같은곳에서 서로다른 ISP를 연결할 수 있도록 장비를 갖추고 회선을 끌어다가 연결해주는 곳이다.

 

그래서 인터넷은 작은 숫자의 잘 연결된 커다란 네트워크를 중심으로 해서 연결되는데 tier-1은 commercial ISP가 되겠다. 우리나라로 치면 skt, kt LG 이런 사업자들이다.

Content provider network는 aws같은 곳이다.

728x90

[페킷스위칭과 서킷스위칭의 비교]

 

서킷스위칭에 비해 패킷스위칭이 더 많은 사용자가 네트워크를 사용하도록 허용할 수 있는 방식이다.

 

 

예를들어 link capacity가 1Mbps이다. 그리고 각 사용자가 active 일때 즉 전송할 패킷이 있고 네트워크를 사용하고자 할 때 100kbps의 속도가 필요하다. 그런데 항상 active상태가 아니라 10%의 시간만 active하고 나머지 90%의 시간은 idle 즉 사용하지 않은 시간이다. 

각 사용자가 100kbps의 속도가 필요하기 때문에 서킷 스위칭을 사용하는 경우에는 100kbps * 10하면 1mbps가 나온다. 그래서 서킷스위칭 방식에서는 할당받은 bandwidth를 배타적으로 사용하고 보장을 해줘야 하기 때문에 10명 초과의 사용자를 받을수가 없다.

그에비해서 패킷스위칭 방식에서 만약에 35명의 사용자를 수용했다고 가정하자. 35명 전부 다 이 링크를 사용하려고 하면은 사용할수가 없으니 몇명까지 이 링크를 사용해도 무리가 없을까를 계산해 보니 10명 까지이다. 그래서 35명의 사용자를 받을 때 동시 10명을 초과해서 active상태가 되는 확률은 얼마나 될까를 계산해봤더니 0.0004보다 작은 확률이다. 그러므로 충분히 35명을 수용해도 문제가 없다. 그래서 패킷스위칭방식이 서킷스위칭 방식보다 더많은 사용자를 수용 가능하다. 

 

그러면 0.0004의 값을 어떻게 나왔을까?

10명 이하로 active인거는 상관없고 초과하는 확률을 구하는거니깐 11명이 동시에 active한거를 구해야한다. 사용자 하나가 active할 확률은 1/10이다. 그다음 idle한 상태는 9/10이고,

그래서 사용자 11명이 active이고 나머지는 아닌 확률은 {(0.1)^11} * {(0.1)^24} 이다. 그래서 11명을 뽑는 방법은 35C11이 된다.

 

만약에 35명 이상의 사용자를 받는다면? => 확률이 커진다.

 

 

패킷 스위칭이 데이터를 전송하는 구간에서는 한꺼번에 데이터 전송이 일어나고 상당 기간동안 전송하지 않은 상태가 일어나는 것이 bursty data인데 이럴 경우에는 패킷 스위칭이 잘 작동한다.

Resource sharing을 하기 때문이다.

패킷스위칭은 서킷스위칭 보다 단순하다. (서킷스위칭은 call setup이 필요하다. 그래야지만 자원을 예약하고 할당할 수 있기 때문이다.)

 

Packet delay 와 loss에 의해서 과도한 혼잡상황이 벌어질 수 있다. 서킷스위칭에서는 딱 정해진 사용자만 받아서 서비스 하지만 패킷스위칭에서는 그보다 훨신 더 많은 사용자를 수용해서 서비스 하기 때문이다. 그래서 신뢰성 있는 데이터 전송, congestion control등을 위해 프로토콜이 필요로하게 된다.

 

Circuit-like behavior의 제공 방법이 있나?

즉 패킷스위칭에서 보장성 있는 행위를 제공해줄 수 있는 방법이 있는지 의문이 발생할 수 있다. 이전의 인터넷 서비스는 텍스트 위주였지만 오디오나 비디오, 즉 멀티미디어 어플리케이션이 대부분 차지하게된 인터넷 상황에서는 bandwidth를 보장해주는 서비스가 필요하게 된다.  그래서 이 문제를 풀기위해 계속 노력중에 있다.

 

인간사회에서 유사한 사례

 

서킷 스위칭 : 음식점 예약, 기차표 예약, 등등…

패킷 스위칭 : on demand allocation

 

 

728x90

[네트워크 코어에서 사용할 수 있는 또다른 스위칭 방식에 circuit switching이 있다. (회선 교환 이라 부른다.)]

 

서킷 스위칭 방식은 패킷 스위칭이랑 많이 다르다. 

서킷스위칭 방식은 전통적인 전화망에서 사용이 되었다. 

서킷스위칭 방식에서는 source와 destination사이에 call(전화 통화)을 위해서 end-end간에 resource(자원)을 예약하고 할당하는 방식을 취한다. (패킷스위칭에서 없었던 방식)

 

다이어그램(옆 그림)을 보면 각 링크가 4개의 서킷으로 나누어 져 있다. (가상의 회선임. 물리적으로 쪼갠게 아닌 논리적으로 쪼개놓은거임. 쪼개는 방식은 다음에 배운다고함)

 call을 통하는 top에서는 2번째 서킷 오른쪽에서는 첫번째 서킷을 차지한다. 즉 예약하고 할당해서 사용하게 된다. 

이 resources는(왼쪽 위, 오른쪽 밑 컴퓨터) dedicated 방식으로 사용하게 된다. 즉 전용으로 쓰는것이다. 공유를 안하고, 회선처럼 보장되는 성능을 담보할 수 있다. (패킷스위칭 방식이랑 다른점이다.)

저 두개의 resource가 아무런 통화작업, 또는 전송할 데이터가 없더라도 다른사람은 이 회선은 쓸 수 없다.

위와 같은 방식이 전통적인 전화망에서 사용되면서 전화 품질을 일정수준에서 유지시켜줬다.

 

 

[FDM versus TDM]

 

FDM (주파수 분할 다중화) 

y축은 주파수, x축은 시간.  Frequency band를 쪼개어 사용자 4명을 가정했을 때 각각의 유저에게 각자의 것을 할당해주는 것이고 각자의 노선만 쓸 수 있다.

 

TDM (시분할 다중화)

frequency band를 쪼개는게 아니라 link를 사용하는 시간을 짤라 번갈아가며 쓰는 방식이다. 주기적으로 각자가 쓸 수 있는 시간이 돌아온다. 시간마다 쓸 수 있는 시간이 있고 해당 시간에는 해당 유저만 사용 가능하다.

 

위 두 방식 둘 다 dedicated 방식으로 사용하게 된다. 

728x90

routing과 forwarding이 있다.

 

routing은 패킷 스위치에 패킷들이 source부터 destination까지 거치게 되는 루트를 결정하는 것이다. rouing algorithm에 의해서 경로 계산이 된다. 이렇게 계산된 경로에 따라서 각각의 라우터에서는 local forwarding table을 만들게 된다. 이 table에서는 source부터 destination까지 가는 경로를 거쳐가기 위해서는 해당하는 라우터에서 output link 뭐를 선택해서 나가면 이 경로를 타게되는지를 표시하는 테이블이다. (그 output link를 각각 패킷의 header value(해더값)에 의해서 정해지게 된다.

 

forwarding이라고 하는것은 패킷들을 라우터의 input으로 부터 routing에 의한 적절한 router output쪽으로 패킷을 옮기는 작업이다. (라우터가 하나의 interchange라고 하면은 각각의 interchange에서 어느길을 택해야 하는지를 결정하는 것이다.)

 

 

*interchange : 교차로

728x90

 

 

[페킷스위칭 방식에서는 store and forward 방식이 사용됨(저장하고 전송한다는 뜻)]

각 패킷당 L bits로 이루어 져 있다. 

Link capacity는 R bps로 가정했다. 

 

전송을 한다는 것은 해당 패킷을 링크에다가 올리는 작업을 얘기함.  

패킷을 쏘면은 링크를 거쳐서 전파가 되어서 라우터에 도착하게 되는데 라우터에 쌓이는 모습이다. 다음 링크로 바로 전송해도 될 것 같지만 그게 아니라 라우터에서 다 채워질 때 전송이 된다. 그래서 (store and forward 이다.)

 

source로 부터 다음 라우터 까지 가는 시간은  L/R이다. (전파 되는데 딜레이 되는 시간은 0으로 가정한다.)

 

 

 

 

 

[페킷 스위칭에 queueing delay, loss가 있다.]

 

라우터에 A와 B로 부터 패킷들을 받고 있다. 도착한 패킷들을 머물렀다가 내 보내야 하는데 머무는 메모리 또는 버퍼를 “queue”라고 부른다. (FIFO의 성질을 가지고 있으며 먼저 도착한 서비스를 먼저 내보낸다.)

이때 queue에서 기다리는 시간이 존재하는 것이queueing delay이다.

 

queueing and loss

링크의 arrival rate(도착률)이 일정 기간 동안에 링크에 transition rate(전송률)을 초과하는 경우에 

  • 패킷들은 queue 보관이 되서 링크에 전송되기를 기다리게 된다.
  • queue 형성하고 있는 버퍼나 메모리가 차면 뒤에 오는 패킷들은 버려지게 된다.

 

 

728x90

[네트워크 코어]

  • 라우터들이 연결되어있는 모습이 네트워크 코어가 형성되어 있다고 말한다.  
  • 네트워크 코어에서는 패킷스위칭 방식( 패킷교환 방식)을 사용한다.
  • 패킷 교환 방식에서는 호스트가 어플리케이션 레이어의 메시지를 좀더 작은 데이터 덩어리로 자른다. (이 메세지의 덩어리를 패킷으로 부른다.)
  • 쪼개진 패킷들은 각 라우터에서 라우터로 전송이 되게 되는데 전송이 될 때 커뮤니케이션 링크를 타고 전송이 된다.
  • 요소(source)로 부터 도착지 까지 경로를 따라서 각각의 링크를 거쳐 패킷 전송이 된다.
  • 패킷스위칭 방식에서 각 패킷은 링크에서 사용할 수 있는 최고속도로 전송되게 된다.  (패킷 하나를 전송할 때 다른거 안하고 해당 패킷만 전송한다는 것, 즉 한번에 링크를 사용할 수 있는 것은 하나디.)

 

 

+ Recent posts