그 중 어떤 블로그들은 " 이 블로거는 다른사람들이 이 글을 보고 이해한다고 생각하나? 너무 성의없게 썻는데? " 라는 생각을 들게하는 블로그가 많았다. 그러면서 다른 사람들은 내 블로그를 보면서 정말 이득이 되는 공부를 할 수 있게끔! 세세하게 적어야지 마음먹고 시작한 블로그.
이번주 부턴 나도 조금씩 짧아질 것 같다.( 그래도 내 자존심이 허락하는 한 길게 쓸거야!! )
넥스터즈에서 CTO역할을 맡은것이 한 몫을 했지ㅎㅎ
나에겐 벅차지만 넥스터즈의 내부 회칙상 신입 회원중 5명이 운영진을 맡는다.( 날 믿어주니 고마운거지 ㅋ )
나 같은 경우는 개발직의 최고 기술자 직을 맡은것 ( 잘 몬하는뎅.. )
처음에는 이번학기 27학점을 수강해서 많은 내용을 블로그에 담을 수 있을것이다 라는 생각을 했지만, 점점 힘들어지넹ㅋㅋ
첫 안드로이드에 2개의 포스팅을 했는데 지금보니 내가 생각해도 나만 볼 수 있게끔 한 것 같네 이것도 빠른 시일내로 바꿔야 하고.
포스팅의 첫 부분은 안드로이드의 전반적인것과 서버개발에 대한 내용을 작성하고 싶었지만 내게 주어진 24시간은 너무 짧다 ( 잠도 많이 자고싶고.)
그 때문인지 몰라도 요즘 나의 미녀 지윤이를 못본다. 그럼에도 불구하고 이해해주는 지윤이가 사랑스럽다.
알고리즘에 대해서도 포스팅 해야하고! 삼성 소멤도 지원하려 했지만 소멤은 이번기회는 그냥 넘겨야 할 것 같은 느낌이 든다.
디폴트 마스크와 서브넷 마스크는 bit operation 을 주로 사용합니다. 이 부분을 공부 하면서 " 아.. C언어도 따로 포스팅을 해야겠군 " 이라는 생각이 많이 들었습니다. 마스크 내부에서 shift를 사용하기 때문에, 이를 정확히 이해 하려면 C언어에서 shift연산자를 이용해서 많이 갖고 놀아봐야 이해가 빠를 것 같습니다.......앞으로 C언어의 포스팅도 늘려야 하나 생각이 드네요ㅎㅎㅎㅎㅎㅎ
흠흠 또 이상한곳으로 빠지네 ㅋㅋㅋ
시작하죠.
네트워크 주소인 첫 주소는 목적지 주소로 패킷을 전송하는데 사용되므로 매우 중요합니다. 인터넷이 n개의 네트워크로 구성되어 있고 라우터는 m개의 인터페이스를 가지고 있다고 가정합시다. 임의의 호스트로부터 패킷이 라우터에 도착하면 라우터는 패킷이 어떤 네트워크로 보내져야 하는지 알아야 합니다. 라우터는 패킷이 어떤 인터페이스를 통해 전송되어야 하는지 알아야 합니다. 패킷이 네트워크에 도착 하려면 네트워크 주소를 통하여 알아냅니다( 이부분은 나중에 포스팅할 예정입니다.)네트워크 주소를 찾은 후 라우터는 라우팅 테이블을 참조하여 패킷이 전송되어야 할 인터페이스를 찾습니다. 네트워크 주소는 실제로 네트워크의 식별자 입니다. 각 네트워크는 네트워크 주소에 의해 식별됩니다.
네트워크 주소는 네트워크의 식별자 입니다.
여기에서 지난 포스팅에서 했던 이야기를 훑어보고 가겠습니다.
블럭속에서 사용할 수 없는 주소가 몇 번 몇 번 있었다고 했죠~?
-> 블럭 속에선 0번과 255번을 사용할 수 없다고 했습니다!
0번은 네트워크 주소는 블록에서 첫 번째 주소입니다.
0번 주소는 인터넷에 속하는 네트워크를 나타내기 때문에, 라우팅에서 사용합니다.
A,B,C 클래스 어떤 클래스가 됬든 하나의 블럭은 하나의 기관에 부여할 수 있습니다. 기관은 그 주소를 이용하여 잘 나눠서 사용하죠. 이 말은 즉슨, IP를 보면 어디 기관인지를 알 수 있습니다.
예를들어 단국대 IP가 있습니다. 단국대 학생이 IP를 이용해서 인터넷에서 무슨 행동을 하면, 모든 인터넷은 " 아 재 단국대 학생인데! " 라는 생각과 함께, 단국대 학생인 것을 인식하게 됩니다. 이런 원리로 북한이 한국에게 해킹이나 디도스 공격을 날렸을 시 알 수 있는것이죠. ( 북한에게 할당된 IP는 없지만, 북한은 중국에게 IP를 빌려서 사용하고 있습니다. )
이와같이 IP를 알아내면, 해당하는 IP의 블럭이 어디에 소속되어 있는지 알 수 있습니다. 예를들어 10.0.0.0 블럭은 나사에 등록되어 있고~~ 17.0.0.0블럭은 단국대에 할당되어 있고~~ 이런식으로 알 수 있는거죠~
이 주소를 주어지면 많은 정보를 알 수 있습니다.
만약 17.0.0.1 아이피가 있다고 가정합시다.
가장 먼저 할 수 있는 것이, 해당 주소는 A클래스인 것을 알 수 있습니다.( 너무 기초적이죠ㅋㅋㅋㅋ )
그리고, 네트웤주소는 17번 이며, 17.0.0.1부터 17.255.255.255번 까지 나타낼 수 있습니다.(물론 맨 앞의 번호 0 과 255번호는 사용할 수 없습니다.)
이와 같이 네트워크 주소를 주면 클래스를 알 수 있고, 블럭을 알 수 있고 블럭의 범위도 알 수 있습니다.
그러면 네트워크가주소가 아니라 우리가 사용하고 있는 IP주소를 보면 그 IP주소로 부터 네트워크 주소를 알아 낼 수 있는것이 문제입니다!!!!!
이것을 알 수 있어야 하죠!!! 매우 중요합니다! 그래야지 IP주소로부터 네트워크 주소를 알아낼 수 있어야지 그 네트워크주소로부터 클래스와 블럭의 갯수, 그리고 블럭의 범위를 알 수 있기 때문입니다. 그리고 라우팅에 사용할 수 있죠!
기계는 이것을 마스크를 이용해서 계산합니다.
만약 임의의 IP주소 134.45.72.2 라는 IP를 발급받았습니다.
인간인 우리는 보자마자 " 아 블럭의 숫자가 128보단 크고 192보단 작으니 B클래스겠네 쉽고만 " 이라고 말하죠.
하지만 기계는 하드웨어적으로 bit operation을 사용해서 처리할 수 있습니다.
Bit을 왼쪽으로 shift하게되면 ( 이 값은 레지스터에 들어가죠 ! ), 가장 앞에 있던 bit가 register에 input이 되면서, 이 값을 가지고 1이냐 0이냐를 판별할 수 있게 되는거죠.
이와 같이 어떤 IP주소가 들어오게 되면 shift해서 주소를 인식합니다.
위 그림만 봐서는 감이 오질 않는다!
네 그래서 방금 언급한 134.45.78.2를 bit으로 표현 한번 더 해드리죠!
이제 이해가 되시나요!!!
이런 것이 Default Mask ( Network Mask ) 입니다!
인터넷 내의 라우터는 패킷의 목적지 주소로부터 네트워크 주소를 추출하기 위하여 알고리즘을 사용합니다. 알고리즘에 접목시키 위하여 네트워크 마스크를 사용합니다. 클래스기반 주소지정에서의 네트워크 마스크 또는 디폴트 마스크는 n개의 왼쪽 비트들은 1이고(32-n)개의 오른쪽 비트들은 0인 32비트 수 입니다.
패킷의 목적지 주소로부터 네트워크 주소를 추출하기 위하여 AND연산을 사용합니다. 목적지 주소(또는 블록 내의 임의의 주소)가 디폴트 마스크와 AND되면 결과는 네트워크 주소로 나옵니다(위 그림처럼)
라우터는 주소와 마스크에 대해 2진법 또는 16진법으로 AND연산을 적용하지만 클래스가 없는 주소지정에서는 빠른 방법을 사용합니다(10진법 표기법을 사용하여 마스크를 지정한다.)
웹에 대하여 첫 포스팅은 Servlet/JSP을 이용한 간단한 예제코드를 포스팅 하려 했는데 이렇게 빗나가네 ㅎㅎㅎㅎ
해당 포스팅은 OSI7계층의 7계층인 응용 계층과 많은 연관이 있습니다. ( 통신에서의 WWW, HTTP에 대해서는 나중에 포스팅 할 예정입니다. )
이게 웹인지 OSI인지 분류를 선택하는것도 많이 어렵네요ㅋ;
HTTP스펙에 대해서 첫 포스팅을 하는 이유는 이렇습니다~
1. 저 역시 백엔드쪽을 조금 다루는 법을 알고 있지만 사용하고 있는 프로토콜의 정확한 동작 원리와 이론 등 잘 모름
2. 안드로이드 스터디에서 HTTP스펙을 발표 해야됨
3. 요즘 OSI7계층에 대해서 포스팅을 여럿 했는데 이거 공부하면 도움 많이 될거같은 느낌이 옴
4. 오늘 공강 ( 이틀 연속으로 썻..)
5. 이 포스팅은 얼마나 걸릴려나...........
스펙에 대한 내용 내용에 전반적으로 녹아들어 있으며, 포스팅의 첫 부분은 개발을 시작하는 학생/신입 개발자가 알고 있어야 할 내용으로 구성되어 있습니다.
요즘 모든 프로그램들이 MVC패턴이 적용되어 있죠. MVC패턴을 적용하는 이유는, 각 클래스가 단일 책임만을 갖기 때문에 가독성이 높아지고 유지보수가 편하며 기타 등등 많은 이유가 있습니다. 요즘 Java로 서버개발을 할 시 MVC패턴을 적용하기 위해서 스트럿츠 혹은 스프링을 많이 사용하죠. ( 전 날코딩 했었죠ㅜ )
그런 MVC 패턴이 프로그래밍 뿐만 아니라 저희 생활 어디서나 볼 수 있습니다. 뭐~ 예를 들면 부품만드는공장 조립하는공장 이런것도 MVC처럼 나눈것과도 같죠.
이런 MVC패턴이 저희가 사용하고 있는 컴퓨터, 웹 브라우저에도 적용되어 있습니다.
그림에선 Browser라 되어 있지만, 제가 사용하는 Servlet Jsp 기준으로는 WAS(Web Application Server)도 있을 수 있고,
WAS속에는 서블릿 컨테이너 뭐 이런 종류가 있을 수 있죠~!
보통 브라우저는 클라이언트의 프로토콜 및 해석기,제어기 이렇게 세 부분으로 나뉘어 집니다
제어기(보통 하드웨어-키보드,마우스) 로부터 입력을 받아서 브라우저를 통하여 데이터를 전송하고, 데이터를 전송할 때 HTTP,FTP,TELNET 과 같은 프로토콜을 사용하여 데이터를 전송합니다. ( 데이터를 받는애들 - 클라이언트의 요청마다 웹 서버가 해당하는 웹 페이지를를 보내줍니다! 또한 요즘에는 요청이 많은 파일을 메모리에 캐시를 해주죠! )
이렇게 전송된 데이터는 해석기에 따라 HTML 또는 Java , JavaScript 그리고 요즘 많이쓰는 파이썬등등 많이 있습니다.
문서 해석기는 상업적인것들을 예를 들면, 인터넷 익스플로러(IE), 넷스케이프 네비게이터, 파이어폭스,크롬 등등등 많은 종류가 있습니다.
이런 웹 페이지에 접근하기 위해서는 클라이언트 ( 유저 )는 주소를 필요로 합니다. 전 세계에 퍼져있는 웹 페이지들에 대한 접근을 가능하기 위하여, HTTP는 위치 지정자( resource locator )라는 개념을 사용합니다 ! URL( Uniform Resource Locator)는 인터넷에서 어떤 종류의 정보든 지정할 수 있는 표준입니다.
URL은 다음 그림과 같이, 프로토콜, 호스트(호스트컴퓨터) 포트, 경로 네 가지를 정의한놈 입니다.
그림을 2개를 첨부했습니다. 처음 포스팅 할 당시 URL은 "프로토콜 , 호스트 , 포트 , 패스"로 이루어져 있다 라고 생각을 했습니다.
하지만
그림 및 데이터 참고 - ( http://www.slideshare.net/deview/d2-campus-http?qid=bd4f0632-fd05-45b8-bf26-4c7d5953d796&v=&b=&from_search=6 )
보통 스키마는 프로토콜이 라고도 부릅니다.
사용자 이름과 비밀번호가 나오는데, 이는 FTP와 같은 프로톨을 사용할 떄 사용합니다.
그리고 파라미터 같은 경우는 HTTP의 Get방식을 말하는 줄 알았으나 해당 블로그에서는 Get방식이 아닌, 모든 프로토콜에서의 파라미터 데이터를 정의해 줄 수 있는것 처럼 나와 있었습니다.
보통 파라미터 같은 경우는 물음표(?)로 시작하고 데이터의 경계를 앤퍼센트(&)로 구분합니다.
경로 뒤에 있는 세미콜론은 CGI를 개발한 벤더회사마다 다릅니다.
이 부분에 대해서는 자세하게 공부를 하지 못했기 때문에 접어 놓았습니다.
그래서 숨김으로 해놓았고, 정확하게 공부한 다음 정확한 정보라고 인식이 되면 수정 후 글 잠금을 해지하겠습니다.
를 보고 난 후부터 스키마라는 단어를 포함시켜서 포스팅을 해야겠다는 마음이 들었습니다.
프로토콜은 서버와 대화하기 위하여 사용하는 커뮤티케이션(웹 페이지(혹은 문서)를 불러오는데) 사용되는 클라이언트 서버 응용 프로그램 입니다. 웹 페이지를 불러오는 데 프로토콜들도 사용될 수 있습니다.( 이중에는 Gopher , FTP,HTTP,News,TELNET 등이 있습니다. - 이중 가장 많이 쓰이는것은 HTTP임.)
Host는 URL이라고 인식하면 쉽습니다. Host는 인터넷 상에 둘도 없는 이름입니다. 이 URL은 IP주소에 매핑됩니다. IP주소는 숫자로 구성되어 있고 현재 전 세계적으로는 IPv4를 많이 이용하고 있죠.( 제가 포스팅한 것 중에 IPv4도 포스팅 했었죠! ) 그런데 IP주소를 직접적으로 사용하지 않는 이유는, 사용하는 사람들이 쉽게 기억하기 위해서 이렇게 만든겁니다! 보통 " www "란 글자로 시작되는 별칭 이름을 갖습니다. 그러나 이것은 강제적인 사항은 아니므로, 호스트는 자유로운 URL 이름을 갖을 수 있습니다.
URL에 서버 포트를 사용하는 것은 옵션 입니다. 이는 자동차를 구매할 때 옵션을 달 수 있고 안 달수도 있는것과 같습니다. 만일 포트가 포함된다는 이는 호스트와 경로 사이에 위치해야 하죠. 디폴트값은 80포트 입니다.(HTTP프로토콜이 80번 포트에서 작동하기 때문이라 보면 됩니다!)
경로(Path)는 정보가 위치하고 있는 파일의 경로입니다. 보통 해당 서버가 있는 디렉터리에서의 상대경로를 입력하죠.
파라미터, 질의 는 보통 쿼리스트링이라 부릅니다. GET방식이라면 이 데이터는 URL의 뒷 부분에 파라미터로 쭈욱~~~ 붙어서 날아옵니다. ?마크를 필두로 파라미터 이름과 파라미터값을 한 쌍으로 해서 여러쌍일 경우 &로 구분되어서 날라오죠.
WWW에서의 웹 페이지는 정적(static), 동적(dynamic) 및 액티브( active ) 의 세 분류로 크게 나눌 수 있습니다.
정적 페이지(동적 문서)
정적 문서(static document)들은 보통 개발당시 *.html의 포맷을 갖는 애들을 정적문서라 생각하죠.
클라이언트는 해당 웹 페이지의 복사본만을 얻을 수 있습니다. 다른말로 클라이언트가 내용을 변경할 수 없고, 해당 페이지를 관리하는 서버 관리자 혹은 개발자만이 페이지에 변경을 줄 수 있습니다.
보통 정적문서들은 HTML , XML , XSL ,XHTML입니다.( XML,XSML,XHTML 에 대해서는 태그를 정의할 수 있습니다. 보통 XHTML을 이용하여 XML을 만들고, XML을 이용하여 HTML을 만들었죠. 이 부분에 대해서는 멀지 않은 미래에 포스팅 할 수 있기를 기도합니다.)
동적 페이지(동적 문서)
동적 페이지는 브라우저에서 페이지를 요청할 때마다 웹서버에 의해서 생성됩니다. 요청이 들어오면 웹 서버는 동적 문서를 만드는 응용 프로그램이나 스크립트를 수행합니다. 서버는 프로그램의 출력이나 스크립트를 그 문서를 요청한 브라우저에게 응답으로 반환합니다. 각 요청에 대해 새로운 문서가 생성되기 때문에 동적 문서의 내용은 각각의 요청마다 달라질 수 있습니다. 동적 문서의 예는 네이버나, 넥스터즈 홈페이지에서 로그인 하면 서버로부터사용자의 이름, 기타등등 정보를 받는 것입니다.동적 페이지에서는 CGI를 빼놓고 이야기 할 수 없습니다.
공통 게이트웨이 인터페이스(CGI : Common Gateway Interface)는 동적 문서를 생성하고 처리하는 기술입니다. CGI는 동적 문서가 어떻게 작성되야 하는지 입력 데이터가 어떻게 프로그램에 제공되어야 하는지, 출력 결과가 어떻게 사용되어야 하는지를 정의하는 표준들 입니다. ( 제가 읽었던 HeadFIrst Servlet/Jsp에서도 어떤 소림사에서 어떤 CGI를 이용하여 개발을 할 것인가에 대해서 서로 싸우는 전투일화가 떠오르네요 ㅎㅎ )
CGI는 새로운 언어가 아니라, 규약 같은것 입니다. CGI는 언어의 선택은 자유롭게 하되, 따르어야 할 규칙과 용어들의 집합이죠. ( 개발자가 사용하는 언어에 대해서 제한을 받지 않는다는 뜻이죠!)
옛날 프로그램의 대부분은 사용자의 응답에 대응하는 프로그램이 아니라, 사용자가 어떤 응답을 주더라도 같은 응답을 내보내는 고전적인 프로그램들로 이루어져 있었습니다. 많이 멍청하죠??ㅋㅋㅋ 하지만 요즘은 사용자가 입력한 값에 따라 서버는 상황에 맞는 페이지로 응답을 해줍니다.
보통 데이터는 HTML의 태그인 <form> 태그 Body속에 넣어서 보내주죠. 이것을 폼 파라메터라고도 많이 부릅니다.
1. 이렇게 form 태그 속에 있는 데이터들의 양이 적고(URL에는 붙을 수 있는 문자의 최대 길이가 정의되어 있습니다.) 보안과 관련이 없으며, 빠른 속도를 요구하는 Get방식이 있습니다. 서버가 URL을 수신하면, URL부분의 물음표 앞부분으로 사용할 프로그램(페이지)를 선택하고, 물음표의 뒤 부분을 클라이언트의 의해 작성된 데이터로 해석합니다. 이 문자열을 변수에 저장하고, CGI프로그램이 실행될 때 이 변수의 값들을 이용합니다.
2. 데이터의 양이 많고(payload 에 데이터를 넣죠~ 편지봉투에 데이터를 넣는다 라고도 표현합니다.) Post방식으로 보내주는 경우가 있습니다.
여기에서는 Get방식과 Post방식만 설명을 했지만 아래의 표(그림)과 같이 실제론 여러가지의 메소드가 존재합니다.
여기에서 사용되는 Get방식은 표에 나와 있는것 처럼 보안에 취약합니다. URL이 사용자에게 노출이 되기 때문에 보여주지 말아야 할 정보도 모두 공개를 해버리죠. 보통 Get방식은 서버로부터 정보를 가져오기만 하는 용도로 사용하죠. 물론 무엇을 가져올 것인지 결정하기 위해서 파라미터의 힘을 빌리기도 합니다. 하지만 핵심은! 서버로 어떤 update,insert를 하기 위해서 사용하는 것이 아니라 오로지 get하기 위해서만 사용한다는것을 인식해야 합니다!
그리고 Get방식에 대해서 주의할 점이 있습니다. Get 방식은 멱등 메소드라고도 부릅니다.
이 글을 읽으시는 분들은 분명 " 멱등이 뭐시기여...하...***" 이럴거라 생각합니다 ㅋㅋㅋㅋ
멱등이란 DB에서의 트랜잭션이라 생각하면 됩니다. 만약 제가 홈쇼핑에서 빈츠 한 박스를 산다고 가정합니다. 구매에 필요한 집주소라든가 이런 정보들을 다 입력한 뒤 구매버튼을 땅~~ 하고 클릭합니다. 이 경우 결제가 진행 되는 동안에는 결제 버튼을 눌리어지면 안됩니다.(혹은 눌리어 지더라도 2중 결제가 진행되면 안되는 것이죠.) 하지만 실수로 결제버튼을 또...........클릭했습니다! 이럴경우 2중결제가 진행되어버립니다.
이렇게 HTTP1.1스펙에서는 GET,HEAD,PUT메소드들을 멱등메소드라 정의하고 있습니다. (트랜잭션이 없는것! - 혹은 비동기 적인것!)
( 아! 멱등이란 말은 여러가지의 의미를 갖습니다. 하지만 제가 주로 개발하는 환경은 HTTP / 서블릿 이므로, 동일한 요청은 서버에 어떤 잘못된 결과를 책임지라 하지 않고 수행한다는 이야기 입니다! )
이렇게 트랜잭션을 발생시켜야 하는 메소드는 POST메소드를 사용합니다. POST메소드는 HTTP1.1스펙에 의하면 멱등메소드가 아닙니다.
보통 멱등(Idempotent)는 동일한 작업을 한 번이고 두 번이고 몇번이든 계속 할 수 있을 때 사용합니다! (부작용이 없다는 가정하에서 말이죠!)
GET
The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI. If the Request-URI refers
to a data-producing process, it is the produced data which shall be
returned as the entity in the response and not the source text of the
process, unless that text happens to be the output of the process.
The semantics of the GET method change to a "conditional GET" if the
request message includes an If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, or If-Range header field. A conditional GET
method requests that the entity be transferred only under the
circumstances described by the conditional header field(s). The
conditional GET method is intended to reduce unnecessary network
usage by allowing cached entities to be refreshed without requiring
multiple requests or transferring data already held by the client.
The semantics of the GET method change to a "partial GET" if the
request message includes a Range header field. A partial GET requests
that only part of the entity be transferred, as described in section14.35. The partial GET method is intended to reduce unnecessary
network usage by allowing partially-retrieved entities to be
completed without transferring data already held by the client.
The response to a GET request is cacheable if and only if it meets
the requirements for HTTP caching described in section 13.
See section 15.1.3 for security considerations when used for forms.
Fielding, et al. Standards Track [Page 53]
The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line. POST is designed
to allow a uniform method to cover the following functions:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
- Providing a block of data, such as the result of submitting a
form, to a data-handling process;
- Extending a database through an append operation.
The actual function performed by the POST method is determined by the
server and is usually dependent on the Request-URI. The posted entity
is subordinate to that URI in the same way that a file is subordinate
to a directory containing it, a news article is subordinate to a
newsgroup to which it is posted, or a record is subordinate to a
database.
The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response includes an entity that
describes the result.
Fielding, et al. Standards Track [Page 54]
RFC 2616 HTTP/1.1 June 1999
If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location
header (see section 14.30).
Responses to this method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields. However,
the 303 (See Other) response can be used to direct the user agent to
retrieve a cacheable resource.
POST requests MUST obey the message transmission requirements set out
in section 8.2.
See section 15.1.3 for security considerations.
요청 메소드가 나왔으니, 응답코드를 빼 놓고 갈 순 없죠!! ( 사실 이 부분을 어디에 넣어야되나 고민을 많이 했습니다!!)
개발하면서 보통 400번에러는 클라이언트 에러고, 500번대 에러는 서버에러다 이런식으로 많이 감으로 코딩했지만 포스팅 하면서 이 개념을 명확하게 정리했네요. 해당 표는 위키백과를 참고했고, 세세하게 설명이 잘 나와 있습니다.( URL : https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C )
GCI는 서버에서 CGI프로그램( Servlet / Asp / Php etc..)을 실행하고 그 출력을 클라이언트에게 되돌려 주는것입니다. 보통 되돌려 주는 정보는 HTML의 페이지 혹은 그래픽,2진데이터,상태코드 그리고 결과를 캐시하기위한 브라우저 명령어들 또는 실제 출력 대신 기존의 문서를 전송하기 위한 서버에 대한 명령어들일 수도 있습니다.
GCI의 응답은 항상 헤더와 몸체 두 부분으로 이루어 집니다. 어떤 CGI 프로그램이든 먼저 헤더, 그리고 빈 줄 , 그이후 몸체가 나옵니다. 그리고 브라우저는 이 헤더를 이용하여 몸체에 어떤 정보가 올 지 해석합니다.
앞에서 기본이지만 빼놓고 온 이야기가 하나 있습니다. 바로 요청에는 헤더가 있다는 사실인데요 클라이언트의 요청에 따라 각가에 다른 Header를 사용합니다. (방금 말 했다 싶이 CGI들은 헤더를 통하여 몸체에 어떤 데이터가 오는지 인식합니다.) 그렇다면! 헤더에는 어떤 종류가 있는지 알아봐야겠죠?! 헤더에는 General-header , Request-header, Entity-header 이렇게 3가지 종류가 있습니다. 각 헤더들이 포함하고 있는 정보들이 많더라구요, 포스팅 하면서 이 부분에 대해서 깊게 공부하지 못했습니다 ( 종강하면 꼭 후벼팔꺼야..)
해당 정보는 여기에 있습니다 : http://tools.ietf.org/html/rfc2616#section-2.2
각각의 헤더에 포함되어 있는 종류들만 엮어서 그림으로 표현했습니다.
(언제 다 볼랑가봉가)
액티브 페이지(active document)
우리는 클라이언트 단의 프로그램 또는 스크립트 개발을 필요로 하죠. 이들을 Active document(액티브 문서)라 부릅니다.
사실상 웹 페이지에서 액티브함을 표현하기 위해서는 JavaScript라는 스크립트 개념의 프로그래밍 언어를 많이 사용합니다. ( 콜백기반이라 빡침... )
페이지의 액티브한 부분이 적다면 이는 스크립트 언어로 많이 작성합니다. 또한 클라이언트의 의해 해석되고 동시에 수행될 수 있죠.
여기에서 ! 스크립트 소스는 바이너리 형태가 아닙니다! 텍스트로 저장이 되죠~!
HTTP
이제서야 나오다니... HTTP새낑..
HTTP(Hypertext Transfer Protocol)은 WWW에서 데이터를 Access 하는데 주로 사용되는 프로토콜 입니다. HTTP는 FTP와 STMP의 조합과 비슷하게 동작합니다. 이것은 파일을 전송하고 TCP를 사용한다는 점에서 FTP와 비슷하죠. 그러나 이 프로토콜은 한개의 TCP연결만 사용하기 때문에 FTP보다 훨씬 간단하고 달려져 있습니다. 별도의 제어,연결 없이 데이터만 서버로 전송되기 때문이죠!
HTTP는 클라이언트와 서버 사이에서 전송되는 데이터가 SMTP 메시지와 비슷합니다. 그리고 메시지 형식이 MINE과 비슷한 헤더에 의해 제어됩니다.(아래 부분에서 MINE을 설명하겠습니다!) SMTP와는 달리 HTTP메시지는 사람이 읽을 수 없게 전송되고 오로지 서버와 HttpParser에 의해 읽혀집니다.(앞에서 말한 제어기!! HttpParser! )
또한 여기에서 차이점이 있는데, Http는 데이터를 저장하지 않고 SMTP는 데이터를 저장한 후 전송합니다.
( SMTP는 메일 서비스를 개발해 본 개발자 혹은 학생들이라면 다 알고 있는 명칭이라고 생각합니다. 저도 Flook-레시피 큐레이션 서비스를 개발할 당시 비밀번호 찾기에서 사용한 기억이 있습니다. )
HTTP는 TCP위에서 돌아간다고 많이 알려져 있죠. 하지만 HTTP자체는 상태가 존재하지 않는(stateless) 프로토콜입니다. 이것은 클라이언트의 대한 정보가 서버에는 저장되지 않는다는 뜻입니다! 이렇게 정한 이유는 HTTP를 설계할 당시, 지구에 있는 모든 장비들이 인터넷과 접속을 하고 있으면, 많은 메모리와 CPU의 성능을 요구했기 때문이죠. 그렇기 때문에 클라이언트트는 서버에 연결을 맺고, 요청을 보낸 뒤, 응답을 받습니다. 그리고는 연결을 끊죠. 즉 연결이라고 하는 것은 한 번의 요청과 응답을 위해만 존재한다고 생각할 수 있습니다.
그렇다는건 즉, 지속적인 연결이 아니기 때문에 클라이언트가 두 번째부터 맺는 요청은 똑같은 클라이언트언트라 할 지라도 서버는 이를 인식하지 못합니다.서버는 각각 다른놈이 요청했다고 생각하겠죠! UDP처럼!
그렇기 때문에 클라이언트는 서버에게 "나!! 있잖아! 방금전에 ~~ 이거 했었던 클라이언트야! "라는 정보를 흘려줘야 합니다.
이런 문제떄문에 등장한 기술이 세션,쿠키 입니다! 보통 많은 개발 서적에 쿠키가 정말 맛있는 초콜렛 쿠키 그림을 많이 넣죠! 그래서 전 얼마전에 구입한 빈츠 한 박스를 넣었죠!캬캬캬캬캬캬컄컄캬캬캬컄ㅋㅋㅋ
그럼 서버에게 " 나 있잖아!!! 방금 그놈!! " 하는 과정에 대해서 알아보죠!
먼저 사용자는 서버에게 세션이 필요하다는 뜻을 전달해야 합니다. 그래야 서버가 쿠키안에 세션ID를 채우고, 해당하는 세션을 우리에게 발급해 줍니다.
그럼 다음번 요청부턴 클라이언트가 세션 아이디와 함께 요청을 서버로 전달합니다. 그런 다음부터 서버는 클라이언트를 인식할 수 있는거죠.
요즘의 CGI는 대부분 Session을 기본 API로 제공합니다. 즉, 개발자는 옛날엔 Session을 한 땀 한 땀 손수 만들어야 했지만, 지금은 전혀 그럴 필요가 없는거죠!( 한땀한땀 만들어 보고 싶기도 하고ㅋㅋㅋㅋ)
근데 큰 문제점이 있어요! 저 같은 경우에도 학교 컴퓨터에선 웹 서핑 시 시크릿모드를 많이 이용하곤 합니다. PC방에선 쿠키정보를 클라이언트에 저장하지 않구요.
개발자는 물론 이런 상황에도 대처해야 합니다! ( 누구나 편하게 사용할 수 있는 서비스를 개발해야되는 개발자님들..)
이런 경우 URL 재작성 기법을 많이 사용합니다. 그림에서 보여준 JSESSIONID=0AAB6C8DE415를 URL에 붙혀서 재전송 해주도록 개발해야 합니다.
Servlet의 경우 JSESSIONID라 부르고, 다른 CGI에서는 부르는 용어가 다릅니다.
주말이 지나가도~ 포스팅은 계속됩니다~ to be continue(시간아 멈춰라 plzplzplz )
이번 포스팅은 네트워크 계층에서 사용하는 ip주소, 즉 IPv4주소에 대해서 이야기 해보려고 합니다.
IP주소의 길이는 4Byte(32Bit)입니다. 그럼 전 세계에 있는 IP주소의 갯수는 몇 개일까요? 2의 32개 승 입니다.(약 42억 개)
42억개라는 IP의 갯수는 많아 보이지만, 스마트폰의 개발 이후로 , 스마트 폰의 갯수보다 IP의 갯수가 적어졌습니다. 전 세계에 있는 모든 사람들이 스마트폰 혹은 노트북이 있다고 가정하면, IP가 부족하다는건 누구나 다 아는 사실입니다.
이것을 대체하기 위해서 IPv6이 나온겁니다.
하지만 IPv6이 사용되지 않는 이유는, 우리나라의 어느 기관이 IPv6으로 버전업을 시켰다고 해도, 미국에 있는 구글은 IPv4를 사용하고 있으면 통신이 되지 않습니다( 하나는 32Bit고 하나는 128Bit이기 때문이죠.)
전 세계적으로 IPv6을 사용하기 위해서는 어떻게 해야 하냐면..
전 세계에 있는 모든 기기를 동시에 종료하고, 동시에 IPv6으로 업그레이드 한 후 부팅하면 IPv6으로 작동하게 됩니다.
이미 저희가 사용하고 있는 컴퓨터,스마트폰에는 대부분 IPv6주소가 다 들어가 있습니다! 하지만 중간에 있는 라우터는 IP주소를 보기 때문에 옛날 라우터는 새 IPv6을 인식하지 못하기 때문에, 지금은 전 세계에 있는 장비들이 IPv6으로 변경이 된다면, 동시에 리부팅 한다고 계획되어 있다고 합니다. (허브,스위치는 아닙니다! IP주소를 보지 않습니다 !! )
하이튼 그렇고, 본론으로 들어가면
IP주소는 각 바이트당 점(도트)로 구분합니다. IP는 처음에 클래스 개념을 적용하여 IP주소를 지정했습니다. 아직 대부분의 인터넷은 클래스 기반의 주소를 사용하고 있고, 아닌곳도 있습니다.
클래스는 총 5개의 종류가 있습니다. - > 클래스 A,클래스 B,클래스 C,클래스 D,클래스 E
IP주소는 전체적으로 42억개가 있습니다. 그리고, 이 IP주소를 사용하기 위해서 5개의 클래스로 나누죠. ( 설마 5등분으로 나눈다고 생각하시진 않으시겠죠..?)
컴퓨터는 2진법이기 때문에, 2등분 하는 것이 가장 좋다고 알려져 있습니다( android에서 image cache할 때도 2의 제곱으로 많이 하죠.)
그렇기 때문에 A클래스는 21억개가 되고, 나머지 21억개를 B,C,D,E클래스가 갖습니다.
그 다음 21억개(2의 32승 -1개) 를 반을 나눠서 B클래스에 10.5억개를 , 나머지를 CDE클래스들에게 줍니다. 또 반을쪼개서 C클래스와 DE, 반을쪼개서 D와 E . 이런식으로 나눕니다.(그림 참조 , D클래스부턴 공간을 위해 가로로 그렸습니다.)
이렇게 나누면 저희가 볼 땐 더 힘들어 지는 느낌이 팍팍 드는데!!! 하지만 이렇게 나눔으로써 계산이 참 편리해집니다.!!!!(어처피 내부에서 일어나는 거니까 우리랑 상관없찡)
다음 그림은 메모리를 표시해준 그림 입니다. 그리고 4Byte일 경우를 생각해서 그림에 Bit를 표시해 봤습니다. (해당 그림에선 비트를 생략했기 때문에 혼란이 있을 수 있으나, 32비트를 그리다가 더러워질 것을 생각해서 생략했습니다. 그리고 E클래스는 D클래스와 같은 넓이를 갖고 있지만, 사실상 E클래스가 D클래스보다 ½배 작습니다.)
이렇게 A클래스와 B클래스의 차이는 , 맨 왼쪽 Bit가 1이냐 아니냐의 차이 입니다.
그리고 B클래스와 C클래스는 앞쪽의 bit의 갯수가 1개냐 2개냐에 따라서 좌지우지 하는 것 이죠.
이렇기 때문에 컴퓨터에서 모든 값을 2로 나누는 것이 제일 효율적인 겁니다.
그니까! 좀 더 쉽게 보면!!!
맨 앞쪽의 Bit가 0이면! A클래스 이다!
맨 앞쪽의 Bit가 1이면! 다음 Bit도 검사! 그 다음 Bit가 0이면 B클래스! 1이면 C클래스! 이런식으로 검사 하는것!
-> 이런것들을 분할 정복 알고리즘으로 많이 쓰기도 하지..
C언어에서는 Bit operation ( shift 연산자 )로 많이 사용하죠! - Bit operation을 사용하기 때문에 속도도 엄청 빠르죠!
그럼 여기에서 , 사용자가 보고 있는 10진수의 주소는 몇에서 몇 까지가 무슨 클래스인지를 인식할 수 있어야 합니다. 보통 저희가 사용하는 인터넷은 192.x~~, 172.x~~를 많이 사용합니다. 그럼 이제부터 알 수 있죠! 우리가 몇 클래스의 ip를 받아서 사용하고 있는지.
저희는 192와 172로 시작하는 IP를 많이 보게되죠!
192.x~로 시작하는 사용자는 C클래스 , 172로 시작하는 ip를 부여 받은 사람은 B클래스를 부여 받은 것 입니다.
위의 그림처럼 IP주소는 해당하는 각각의 클래스들( A,B,C,D,E클래스) 에 대해서, Netid와 Hosid로 나뉘어져 있습니다.. 이건 즉 사람도 성과 이름으로 이루어 져 있는 것 처럼말이죠. (일단 그룹핑을 한 것입니다.)
데이터가 계층화 되어 있는겁니다! ( 단계층 되어 있는건 이름만 있고 성이 없는 것! - 우리나라의 옛날 평민들이 성이 없는것과 같죠 .)
왜 이렇게 사용했냐면, 이름을 줄 때, 이름을 유일성때문에 이런 방법을 선택했습니다.
이 세상에 유일성을 보장하고, 만약 성이 없다는것을 가정하면. 전 세계에 있는 사람들은 제가 이미 기호라는 이름을 선택했기 때문에, 다른 사람들은 기호라는 이름을 선택하지 못합니다. 하지만 성이 있다고 가정하면, 이기호,박기호,권기호 라는 이름을 갖을 수 있게 됩니다. (충돌이 나지 않는 것 입니다.)
IP주소는 전 세계에서 유일해야 하기 때문에 다음과 같은 방법을 선택한 것이죠. 그래서 IP도 사람과 같이 hosid와 netid로 나눈겁니다. - 3계층에서 IP로 상대방을 구분할 수 있어야 되니까요!
A클래스에서는 성을 표시하는 Network id가 1바이트, 그리고 이름을 표시하는 Hostid가 3바이트 입니다.
-A클래스에서는 성을 128개만 표현할 수 있지만( 왜 128개인지 잘 숙지 해야합니다!! ), 이름은 2의 24승개를 표현할 수 있습니다.
B클래스에서는 성을 표시하는 Network id가 2바이트 이름을 표시하는 Hostid가 2바이트 입니다.
- B클래스에서는 성을 2의 24개승을 표현할 수 있지만, 이름은 2의 24개승 밖에 표현을 하지 못합니다.
C클래스에서는 성을 표시하는 Network id가 3바이트 이름을 표시하는 Hostid가 1바이트 입니다.
-A클래스와 반대로 생각할 수 있죠!
여기서 생각을 해보고 넘어갑시다.
A클래스는 성 1개당 2의 24개승의 이름을 표기할 수 있습니다. 이 말은 즉, 그만큼 더 많은 자식을 갖을 수 있다는 뜻 입니다. 하지만 A클래스는 현재 미국에서( 미국에 달파라는 곳에서 인터넷이 시작했기 때문이죠 ,초기의 연구용 네트워크가 퍼진 경우. ) 거의 다 가지고 있습니다.
B클래스는 유럽, 일본, 그리고 한국도 조금 가지고 있습니다. 거의 1980년대에 B클래스까지 다 할당을 받아갔죠.
제가 다니고 있는 단국대학교는 C클래스 입니다. 그렇기 때문에 저희 학교 학생들이 다 사용하기에는 터무니 없이 부족하기 때문에 저희에겐 가상 IP를 발급해 줍니다. ( 192~ 172~ 이런 아이피들이죠. 이것들을 사설 아이피라 부릅니다. )
각 클래스는 고정된 수의 블럭을 갖습니다.
각 블럭은 고정된 크기를 갖는데, A클래스는 128개(2의 (8승 -1)개 ( 여기서 -1개를 하는 이유는 , 각 클래스마다 앞에 자신의 클래스를 나타내는 bit가 있기 때문에 자신의 클래스를 나타내는 bit를 빼준겁니다. 즉 A클래스에서는 맨 앞의 0이 A클래스를 나타내 주죠.)) , 블럭은 사람으로 보면 성씨를 갖고 있어야 자손을 퍼트릴 수 있죠. 이 성을 블럭이라 부릅니다.
컴퓨터는 2의 지수승으로 쪼개면, 뒷쪽은 똑같은 패턴으로 반복되고, 앞쪽은 0,1,2,3으로 순서가 증가가 됩니다.
이런 똑같은 블럭이 A클래스엔 128개가 있는겁니다.
그럼 A클래스는 이름 하나당.. 1600만개(2의 24승)의 IP를 갖을 수 있는거죠
여기서 못쓰는 IPid가 있습니다.
IPv4에서 Netid 0번,10번 ( 사설IP에서 사용) , 127번(루프백) 은 사용하지 못합니다. (A클라스에서 1600만개 *3개의 아이피를 사용하지 못합니다.)
그렇다면, 각 IP는 73.0.0.0 부터 255.255.255.255까지 IP를 줄 수 있다는 말이 되죠?
근데 여기에서도 또!!!!! 또~!!!!!!!!!!!!!! 사용하면 안되는 IP가 있습니다. 바로 73.0.0.0 ( 끝이 0 )인 경우는 그 집의 네트워크 주소( 권씨집안의 주소라 생각하면 편하죠! ) 입니다. 73.0.0.1부터 사용이 가능합니다. 그리고 255.255.255.255는 모두 라는 뜻 입니다.( 권씨집안의 모든 사람들은 들어라! 라는 뜻!) 이 주소는 같은 네트워크 주소 속에 있는 모든 컴퓨터들에게 데이터를 써서 보낼 때 이 주소를 사용합니다. - 보통 라우터를 254번을 줘버립니다.
정리를 해보면,
A클래스에서는 0,10,127 Netid를 못 쓰고, 블럭으로 들어가면 시작주소인 0번지와 맨 끝번지인 255번을 사용하지 못합니다 그리고 254번은 라우터한테 줘버립니다.
B클래스는 블럭의 수가 2의 14승개( 약 16000개) 입니다.(16-2개, B클래스를 나타내는 bit가 2개라서)
C클래스는 블럭의 수는 2의 21승(24-3) 약 200만개가 있습니다. 한 개의 블럭당 IP는 256개를 받을 수 있습니다. (수가 너무 적기 때문에, 교수님들의 사무실, 행정실 이런곳에만 공인IP가 들어가고 나머지 실습실 이런곳에는 사설IP가 들어가게 됩니다.)
C클래스는 보통 가정집 혹은 벤쳐에서 사용하게 됩니다.
D클래스는 멀티캐스트( 유료채널에서만 사용!)
E클래스는 미래에 사용하기 위하여 남겨둔 클래스 입니다.
벌써 세시 반을 넘겼네요~
포스팅을 대충써도 세시간이 넘다니~
상세하게 적으면 더 오래 걸리겠네요 ㅎㅎㅎㅎ
좀 더 자세한 포스팅은 아침 수업 다녀오고나서 랩실에서... 좀 더 상세하게 작성하도록 하겠습니다~
Bridge는 1,2계층을 갖는 놈입니다.(보통 브릿지는 포트가 2개입니다. 포트가 여러개 인 것은 2계층 브릿지- swtich라고도 합니다!)
Router는 1,2,3계층을 다 갖는 놈 입니다. ( 하드웨어적으로 가까운 얘를 3계층 스위치라고도 하죠! )
Repeater : 물리계층에서만 동작하는 장치입니다! 거리가 멀어지면 신호가 약해집니다. 네트워크 내에서 정보를 전달하는 신호는 신호의 감쇠가 데이터 무결성을 훼손하기 전까지는 고정된 거리를 이동할 수 있습니다. 리피터는 신호가 너무 약하게 되거나 훼손되기 전에 신호를 수신하여 원래의 비트 형태로 재생(위 그림이 참고)합니다. 그런 다음 리피터는 새롭게 생성된 신호를 전송합니다. 과거에는 이더넷 LAN이 버스형 접속형태를 이용할 때 동축케이블의 길이 제한을 극복하기 위해 LAN의 두 세그먼트를 연결하는데 사용되었습니다. 그러나 오늘날 이더넷 LAN은 성형 접속형태를 이용합니다. 성형 접속형태에서 리피터는 허브(Hub)라는 다중포트 장치입니다.
일상 생활에서 거리가 멀어지면, 멀리 있는 사람이 제 이야기를 못 듣는 것과 같죠! 그러면, 멀리 있는 사람에게 제 이야기를 들려주기 위해서는 중간에 제 말을 전달해 줄 사람이 필요합니다. 위의 그람과 같이 repeater는 그런 역활을 하죠!
1. 물리 계층에서만 동작하는 장치.
2. 거리가 멀어지면 신호 감쇠(신호 약화)발생
3. 신호 감쇠는 데이터 손상의 요인
4. 약화된 신호를 원래 크기로 증폭하는 기기
-> 리피터는 연결할 수 있는 팔이 2개입니다(서로 다른 두 기기만 연결할 수 있음 팔이 많아지면 허브라 부름.)
5. 리피터는 LAN 세그먼트를 연결(10Base5에서 사용)
6. 필터링 기능이 없어서 모든 패킷을 전송( 이게 단점 입니다! )
허브(Hub) - 트리구조로 엄청 많이 연결할 수 있다.
1. 다중 포트 리피터 ( 10BaseT 등에서 사용)
- start형 포톨리지에서 다 들어오는 놈이다.
Cost가 낮으며 성능면에서 엄청 떨어진다.(다른 놈이 사용할 경우 성능이 급격히 떨어진다)
만약 A라는 컴퓨터가 B에게 데이터를 전송하게 되면, 같은 허브에 연결되어 있는 다른 컴퓨터들은 데이터를 동시에 수신할 수 있습니다.
리피터는 모든 비트를 내보내지만 필터링 기능을 갖고 있지 않습니다.(해당 그림 참조!)
허브나 리피터는 물리 계층 장치입니다. 이들은 데이터링크 주소를 가지고 있지 않고, 수신된 프레임의 데이터링크 주소를 확인하지 않는다. 단지 훼손된 비트를 재 생성하여 모든 포트로 내보내기만 합니다.
브릿지(Bridge)
브릿지(bridge)는 물리 계층과 데이터링크 계층에서 동작합니다. 물리 계층 장치로써 수신하는 신호를 재생합니다. 데이터링크 계층 장치로는 프레임 내에 포함되어 있는 프레임의 발신지,목적지 물리주소(MAC address)를 검사할 수 있습니다. 주소를 검색하여 필터링 기능을 제공합니다.( 브릿지 테이블 관리 수행 -> 인터페이스와 호스트 주소를 관리하는 테이블 ) - 아 ! 그냥 브릿지에는 학습 능력이 없습니다!
브릿지도 Repeater처럼 LAN 세그먼트를 연결합니다.
포트를 2개 갖고 있으며 필터 기능이 없는것(1계층) -> 리피터 | 브릿지 <- 포트를 2개 갖고 있으며 필터 기능이 있는것(1,2계층)
필터링 : 브리지와 리피터의 기능이 무엇이 다른가 하는 질문이 있을 수 있습니다! 브릿지는 필터링(filtering)기능을 가지고 있습니다. 브리지는 프레임의 목적지 주소를 검사하여 그 프레임을 어느 포트로 내보내야 하는지를 결정합니다.
브릿지는 필터링 결정에 사용되는 테이블을 가지고 있습니다.
브릿지도 팔이 두개뿐이 없습니다.
투명브릿지 ( Transparent Bridge)
- 오늘날의 브리지로 학습 브릿지라 한다.
- 초기에는 테이블이 비어있다가 프레임 송 수신을 통하여 인터페이스와 호스트 주소를 학습하여 테이블을 관리한다.
요즘 대세인 인공지능이 대중화 되었다고 생각해 보자!
인공지능이 공장에서 생성이 되어서 우리 집으로 배송이 딱 완료된 상황이라 가정하면!!! 배송이 막 완료된 인공지능은 머리속이 비어져 있죠?! 이 인공지능은 앞으로 행동하기 위하여 모든것을 학습해야 합니다.( A가 B에게 전송한다. C가 D에게 전송한다 이런식으로!)
이것을 학습하기 시작하면, 브릿지는 A,B가 내 왼쪽에 있구나! 라는걸 인식하게 되고, C,D는 내 오른쪽에 있구나! 이런것을 학습하게 됩니다.
이것이 계속적으로 학습하게 되면, 신호가 서로 넘어가지 않도록 합니다.(성능이 업그레이드 됩니다) 서로 넘어가지 않는 다는 것은 필터링이 되었다는 뜻이고, 서로 자신의 구역에서만 통신이 이루어 졌다는 뜻이고, A,B가 대화 하는 것은 C,D는 듣지 못한다는 뜻 입니다.
초창기 브릿지는 정적인 전달 테이블을 가지고 있었습니다. 시스템 운영자가 브릿지를 설치할 때 각 테이블 항목을 직접 손으로 입력했습니다. 이 과정은 간단했지만 실용적은 아닙니다. 새로운 컴퓨터가 추가되거나 컴퓨터 하나가 제거될 때 테이블은 다시 운영자가 수작업으로 변경해야 했기 때문이죠. 만약 한 컴퓨터의 MAC주소가 변경되면 마찬가지로 같은 상황이 발생하는데, MAC주소의 변경은 드문 일이 아니였기 때문에 큰 문제는 되지 않았죠.
정적 테이블보다 더 좋은 해결 방법은 주소를 포트로 자동적으로 변환해주는 동적 테이블입니다. 테이블이 동적으로 만들려면 프레임들의 이동을 보고 점차로 배워가는 브릿지가 필요합니다. 이 일을 하기 위해서는 브릿지는 목적지와 추발지 주소를 둘 다 조사해야 합니다. 목적지 주소는 테이블 확인(table lookup)을 이용하여 프레임 전달 방향을 결정하는 데 사용되며, 출발지 수소는 테이블에 새로운 항목을 추가하거나 변경하는 데 사용합니다.
(학습 브릿지)
1. 컴퓨터 A가 프레임 하나를 컴퓨터 D로 전송할 때, 브릿지는 A,D의 항목을 갖고 있지 않습니다. 이 프레임은 세 포트에 모두 전송되는 , 즉 네트워크에 플러딩(flooding)을 하게됩니다. 그러나 출발지 주소를 보고 브릿지는 컴퓨터 A가 1번 포트에 견결된 LAN에 있다는 것을 배웁니다. 이것이 의미하는 것은 A로 가는 프레임들은 다음부터는 포트 1를 통하여 전송된다는 것을 배웁니다. 브릿지는 이 항목을 테이블에 저장하여 첫 번째 항목이 되게 합니다.
2. 컴퓨터 D가 프레임 하나를 컴퓨터 B로 보낼 때 브릿지 B에 대한 항목이 없으므로 브릿지는 이 프레임을 또 네트워크에 플러딩 하고 테이블에 항목 하나를 추가하죠.
3. 이 학습은 테이블이 모든 포트에 대한 정보를 가질 때 까지 계속 됩니다.
그렇지만 이 학습 과정이 오랜 시간이 걸릴 수 있습니다. 예를 들자면, 만약 어떤 컴퓨터가 프레임을 전혀 보내지 않는다면(거의 없다는 거죠!) 이 컴퓨터는 테이블에 항목을 가질 수 없습니다. 투명하다는 뜻은 안 보인다는 뜻 입니다. 유리를 정말 깨끗히 닦아놓으면, 유리가 있는지 없는지 모릅니다. 이것이 투명한것이죠!
예를 들면, 우리 입장에서 인공지능이 투명한 것 입니다. 인공지능이 부팅 되서 얼마나 학습이 되었는지 신경쓸 필요가 없습니다. 그냥 저희 인간끼리 대화를 하면 인공지능이 알아서 학습을 하는 것 이죠. ( 우리는 인공지능을 전혀 생각할 필요가 없어집니다 ) 이해됬나염?
음~ 브릿지지는 2계층 교환기 이죠?( 2계층 switch라고도 부르며, 원래의 브릿지는 포트가 2개가 있습니다. 포트를 여러개로 늘린것을 2계층 브릿징 스위치 , 2계층 스위치라 부릅니다 )
교환기는(switch)라는 용어를 사용하면 스위치가 두 가지 서로 다른 의미를 가지므로 조심해야 합니다. 이 용어는 장비가 동작하는 계층에 추가하면 명확해 질 수 있습니다. 교환기는 2계층 교환기와 3계층 교환기가 있습니다. 2계층 교환기는 물리 계층과 데이터링크 계층에서 동작하는데 보다 빠른 포워딩 기능을 갖는 브릿지가 됩니다.
라우터.
라우터는 1,2,3계층까지 커버하는 장비입니다. 라우터는 IP주소를 쳐다보게 됩니다. ( 브릿지는 물리 계층 주소를 쳐다봅니다 ) , 라우터는 소프트웨어 적인 프로그램이라 생각하면 됩니다. 라우터(router)는 물리 계층, 데이터링크 계층, 네트워크 계층에서 동작하는 3계층 장치입니다.. 물리 계층 장치로써, 수신한 신호를 재생하고. 데이터링크 계층 장치로써, 패킷 안에 포함된 물리 주소 ( 발신지와 목적지 ) 를 검사합니다. 네트워크 계층 장치로써라우터는 네트워크 계층 주소 ( IP 계층의 주소 ) 를 검사한다. 브리지는 충돌 도메인을 변경하지만 라우터는 브로드캐스트 도메인을 제한한다.
라우터는 3계층(물리 계층, 데이터링크 계층, 네트워크 계층)장치이다.
라우터는 LAN들을 연결할 수 있으며 WAN들을 연결할 수 있고 LAN과 WAN을 연결할 수도 있습니다. 즉, 라우터는 네트워크 간 연결장치로, LAN과 WAN을 서로 연결할 수 있습니다. 라우터는 인터네트워킹 형태로 독립적인 네트워크를 연결하는 인터네트워킹 장치입니다. 이 정의에 따라 라우터로 연결한 두 개의 네트워크(LAN과 WAN)은 네트워크 또는 인터넷으로 연결이 됩니다.
리피터 또는 브리지는 LAN의 세그먼트를 연결합니다. 라우터는 인터네트워크(인터넷)을 구성하기 위해 독립적인 LAN 또는 WAN을 연결합니다.
라우터는 인터네트워크(인터넷)를 구성하기 위해 독립적인 LAN또는 WAN을 연결합니다.
라우터와 리피터 또는 브릿지는 세 가지의 중요한 차이가 있습니다.
1. 라우터는 각 인터페이스를 위한 물리,논리(IP) 주소를 가지고 있습니다.
2. 라우터는 물리적 목적지 주소가 패킷이 도착하는 인터페이스의 주소와 일치하는 패킷에서만 동작한다.
3. 라우터는 패킷을 전달할 때, 패킷(발신지와 목적지)의 물리 주소를 변경한다. - (앞 포스팅에서 말 했다 싶이, 서로 연결되어 있는 두개의 장치에서는 다른 프로토콜을 사용할 수 있기 때문에, 변환해 주는 작업도 필요합니다.)
이더넷 LAN에서 보내지는 패킷을 프레임(Frame)이라 합니다. 이더넷 프레임은 7개로 구성되어 있습니다~!! 구성되어 있는 것들은
서문(preamble) , SFD , DA , SA , 데이터단위의 길이 또는 유형, 상위 게층의 데이터, CRC입니다.
여기에서의 2계층의 프레임은 DA~CRC까지 입니다.
이더넷은 신뢰할 수 없는 매체에서 사용되는 수신된 프레임의 확인응답 매커니즘은 제공하지 않습니다. 확인 응답은 상위 게층에서 구현되어야 합니다.
이더넷 프레임의 형식을 볼까요!(Mac 프레임의 형식이라고도 하죠!)
* 여기 이후로 나오는 지국 은 목적지/발신지의 컴퓨터라고 생각하시면 됩니다
Preamble(서문)
0과 1이 반복되는 7바이트(56bit)가 들어있는 802.3 프레임의 첫 번째 필드는 시스템의 들어오는 프레임을 수신하게 하고, 입력 타이밍을 맞추게 합니다. 패턴은 단지 경고와 타이밍 펄스를 제공합니다. 56bit 패턴은 프레임의 시작으로 지국이 일부 비트를 놓치는 것을 허용합니다. 실제로 서문은 물리 계층에서 추가 되므로, 프레임의 일부가 아닙니다.
Start Frame Delimiter(SFD - 시작 프레임 식별자)
두 번째 필드(1Byte-10101011)는 프레임의 시작을 알립니다. SFD는 지국이나 지국자들에게 동기를 맞추는 마지막 기회를 제공합니다. 마지막 두 비트 11은 수신자에게 다음 필드는 목적지 주소임을 알립니다. SFD도 물리 계층에서 더해집니다.
프레임은 Destination address에서부터 시작합니다. ( 대부분의 프로토콜에서는, 제일 앞에 목적지 주소가 오게 됩니다. 왜냐하면, 이 데이터가 원래 저에게 보내려고 했던 데이터 인지 아닌지를 판가름 하기 위해서 입니다.)
통신을 할 때 기계는 이 소리 저소리 어떤 소리든 자연에서 오는 소리인지, 혹은 다른 컴퓨터에서 발송되는 소리인지 구분하기 위하여 패턴을 사용합니다.
만약 패턴이 있으면, 인공적인 것이고(지능을 갖고 있는 놈이 만드는 것이고) 패턴이 없으면 자연에서 우연히 만들어 진 거라고 생각합니다.
이해를 돕기 위하여~! 저희가 컴퓨터라 생각해 봅시다!
전선에 신호가 신호가 들어오는지 인식하고 있다고 하면(CS 을 하고 있다고도 하죠!- Carrier Sence), 이 전선에 들어오는 데이터가 계속 들어오지만 데이터인지 잡음인지 인식하기 위해서는 규칙성으로 인식을 해야 합니다.
왜 이렇게 인식을 할까요~? 이건 외국인이 저희에게 말을 걸 때, 처음에 뭐라고 시작 했는지 기억이 안나는 것과 같습니다.
외국인이 What~~~~ Where~~ 이라고 물어보면 멍 때리고 있었던 저희는 그 첫 문장을 못 듣고, 뒷 부분만 듣게 되죠.
신호가 (2계층 프레임이) 들어오기 전에 신호를 계속해서 줍니다(01010101 이런식으로). 그럼 기계는 이 패턴을 초기에 인식을 하든, 몇 bit혹은 몇 byte를 놓히고 나서도 패턴을 인식한 후, 이렇게 생각합니다 "아 누가 나한테 말을 할란갑네~~!!!!??"
여기에서 패턴의 종료를 위에 그림과 같이 10101011 이런식으로 패턴의 종료를 11로 끝내버립니다. ( 1과 0이 연속해서 들어오다가 1이 두번 들어오면 Data의 시작이라는 것을 알 수 있죠.)
그럼 Destination address부터 CRC까지 인식할 수 있습니다.
인간으로 치면 , 누군가가 말을 하기 전에 헛기침을 하면서 시작한다던가, "주목~!!"이라는 말로 시작을 하는 것과 같은거죠.(이런 패턴은 많은 곳에서 활용합니다.)
Destination Address(DA - 목적지 주소)
목적지 주소 필드는 6Byte이고, 패킷을 수신하는 목적지 지국(컴퓨터) 또는 지국(컴퓨터)들의 물리 주소가 들어가 있습니다.
Source Address ( SA - 발신지 주소)
SA필드도 6바이트이고, 패킷 송신자의 물리주소가 들어가 있습니다.
여기에서 목적지 주소와 발신지 주소는 똑같이 6byte입니다. 하지만 모든 프로토콜이 6byte는 아닙니다. 이더넷과 무선랜이 6byte입니다.(다른것도 6byte일 수 있고, 혹은 길거나 짧을 수 있다는 소리죠.)
LengthPDU( or length or type , 발신지 주소)
이 필드는 길이 또는 유형 필드를 나타냅니다. 원래의 이더넷은 이 필드를 MAC 프레임을 이용한 상위 계층 프로토콜을 나타내는 유형 필드로 사용합니다. IEEE 표준에서는 데이터 필드에 있는 바이트의 수를 나타내는 유형 필드로 사용합니다. 이 두가지 이용은 오늘날 공통으로 사용합니다. 목적지 주소와 발신지 주소 이후에 데이터의 길이가 오는 이유를 알아야 합니다. 길이는 저희가 코딩하면서도 넣을 수 있습니다. 코딩을 하면서 넣어야 할 때는, 정보의 길이가 가변적일때 필요합니다. (길이의 정보가 고정적이면 길이가 필요 없죠!)
C언어로 예를 들면, 메모리에 어디부터 어디까지 데이터를 가져갈 것 인가에 사용하죠. 그 가져갈 만큼의 길이 정보를 LengthPDU에 넣어둡니다. 그리고 데이터를 읽어들일 때 LengthPDU 를 읽은 후, 그 만큼의 데이터를 읽어오죠. LengthPDU가 Destination address와 Source address 뒤에 나오는 이유는, 이더넷 프레임은 Destination과 Source address가 고정적으로 각 각 6byte이기 때문입니다. 이해됬쥬?
Data and padding ( data - 데이터)
데이터 필드는 상위 계층 프로토콜로부터 캡슐화된 데이터를 전달합니다. 최소 길이의 제한은 간단하게 이야기 해줄테지만, 정확한 CSMA/CD동작에 필요한 것입니다. 이더넷 프레임은 최소 512Bit 혹은 64Byte길이를 요구합니다 이 길이의 일부는 헤더와 트레일러 부분입니다. 만약에 헤더와 트레일러의 초소 길이(발신자 주소 6바이트,목적지 주소 6바이트, 길이 또는 유형 2바이트 CRC 4바이트)를 생각해 본다면 18바이트가 되는데 그러면 상위계층으로부터 온 데이터의 최소 길이는 46바이트 입니다. 만약 상위 계층 패킷이 46바이트보다 적다면 이를 만들기 위해 패딩이 이루어 집니다.
Data and padding의 길이는 최소 46byte 최대 1500byte입니다. 여기에서 최소 46byte라는건 무슨 뜻일까요? 많이 익숙하지 않죠? ( 보통 컴퓨터에서는 2진수로 표기되어 2의 배수에 익숙하죠.. 저도 여기에서 뭐지??라는 생각을 많이 했습니다ㅎㅎ)
Destination address(6Byte 이하 B) + Source address(6B) + LengthPDU(2B) + ~(데이터의 길이) + CRC(4B) 에서 가변적인 데이터의 길이를 제외하면, 18Byte입니다.
프레임의 전체 크기를 봤을 때 64Byte부터 시작합니다. 그러기 떄문에 데이터의 최소 길이는 46Byte가 될 수 있는거죠!
그 답은, 요즘 급상승 하고 있는 iot(internet of things) 에서 사용할 수 있습니다. 보통 iot에는 sensor를 많이 사용하는데요, 새로 나오는 sensor에는 사용자들에게 사용할 수 있는 Byte spec을 공개합니다(보통 한번에 보낼 수 있는 바이트를 제공해 주죠). 여기에서 사용자는 제공되는 Byte로 헤더를 설계하고, 전송 가능한 Body를 작성합니다.
그럼 여기에서 최소 데이터길이가 46Byte가 되어야 한다고 나와있습니다. 그럼 이런 생각도 갖을 수 있죠! " 그럼 만약 데이터의 길이가46Byte가 안된다면?? "
그래서 padding이라는 개념을 사용합니다. 데이터 뒤에 붙은 bit를 0으로 채워주는 거죠.
(뒤에서 다시 포스팅 하겠지만, LengthPDU는 여러종류가 있습니다. 정확한 Frame의 길이를 나타내 주기도 하고, Data and padding의 길이만 나타내 주기도 하며, 모
마지막으로 CRC가 뭔지 알아보겠습니다!
CRC는 지금 학습하시는 분들에게는 많이 중요하지 않습니다. CRC는 프레임의 오류 검출 필드라 부르는데, 2계층의 트레일러와 같습니다. (앞 포스팅에서 말 했다 싶이, 트레일러는 오류검출을 하기 위해서 Bit를 짝수로 맞춰주는 역활을 합니다.)
근거리 통신망은 어느 거리를 근거리 통신망이라 할까요? 근거리 통신은 초 중 고등학교, 아파트 등등 저희가 평소에 사용하는 통신망이 다 근거리 통신망 입니다.
랜은 대학교, 혹은 회사 같이 규모가 조금 있는 곳에서 사용합니다. 랜은 제가 다니고 있는 멀티미디어 공학과 전용 랜 이런식으로 빼서 사용하죠.
그런 단과대학의 랜들이 모여서 단국대학교의 랜이 됩니다. 대표적인 랜이 이더넷 입니다. 이더넷은 버스형입니다. 토큰링은? 링형입니다. 무선랜은? 스타형 입니다.
뜬금없는소리
이더넷은 사무실과 집에서 사용하고 공장은 토큰링을 사용합니다. 무선망은 와이파이 입니다.
뭐.. 그니까!! 이더넷은 세계적으로 가장 많이 쓰는 인터넷 입니다
오늘은 이더넷에서 발생하는 이슈중에 하나인 CSMA/CD 에 대하여 포스팅 하려 합니다.
CSMA/CD ( Carrier Sence Multi Access CollisionDetection )
처음 쉽게 설명하고 시작 하겠습니다. 이건 이전에 눈치게임을 생각하시면 됩니다.
4명의 학생에서 눈치게임을 했을 때 , 겹칠 확률도 있지만, 보통 순서대로 1 , 2 , 3 , 4 이런식으로 외치게 됩니다.
이런경우 어떤 알고리즘으로 동작 했을까요?
공기로 누가 말을 하나 안하나 캐리어 센스(다른 사람이 말 하나 안하나 보고 느끼는것)를 한 것 입니다. 만약 다른 사람이 말을 하고 있으면, Chanel이 Busy하다고 말을 하고, 말을 안하고 있으면 Chanel이 free하다고 이야기 합니다.
Carrier Sence Multi-Access - 여러명이 공기를 통하여 일단 말을 합니다.
Collision Detection - 그리고 서로 겹쳤나 느끼는 겁니다. 충돌이 안 났으면 행복한거고, 충돌이 난 경우 다시 게임을 해야 합니다.
쉽죠?
이더넷 통신 네트워크를 사람과 빗대어 이야기 해보겠습니다.
만약 특정한 장소에서 제 친구가 말을 하면, 다른 사람들도 그 말을 듣습니다. 그리고 저도 그 말을 듣고 대답을 하지만, 다른 사람들은 자신과 상관이 없으면 무시를 합니다. 근데 어떤 사람들은 대화 내용을 바탕으로 나쁜짓을 합니다.
예를 들면, 어떤 커플이 인터넷 상으로 데이트 장소를 정하고 있습니다. 그리고 그 인터넷은 암호화가 안 되어 있으면 소리를 다 들을 수 있습니다. 이런 뜻이죠. 인터넷은 이런식으로 동작합니다.
여기서 이런 질문을 던질 수 있겠죠.
뭐...뭐?! 내가 말을 한 것을 다른사람들이 다 들을 수 있다고!? 그럼...내가 지금까지 말 했던것은 다 다른사람들이 보고 있었던거야!? 헐?! 뭐야!!!? 비효율적 아니야!?
답 : 이전 포스팅을 참고하시길 바랍니다.
그럼, 만약 두개 이상의 PC가 프레임을 송신하면 어떻게 될 까? 컴퓨터는 당연히 못알아 먹죠 ㅋㅋㅋㅋ(두개의 소리가 섞여서 못 알아 먹음.) 이렇게 못 알아 듣는 말을 충돌이라 합니다. 충돌이 났을 경우 수신이 불가능하다고 하는 것 이다!(뒤에서 이야기 할 테지만, 이럴때 jamming signal을 던진다)
다시 정리하면,
Carrier Sence(데이터를 보내기 전에, 전송 매체가 사용중인지 알아낸다.-내가 말하기 전에 공기가 사용중인지 확인한다)
Multi Access(전송 매체가 사용중이 아니라면, 내 귀가 사용중이 아니라면 누구든 사용 가능하다.)
Collision Detection (내가 말 하고 있는 도중에 다른 사람이 말을 하면 충돌이 났다고 기계는 생각한다.)
이것이 CSMA/CD 입니다.
그래서 사용하는 기법이 RTS / CTS가 있습니다
station ready to send clear (RTS - 보낼 준비가 완료되었다)
clear to send - CTS
A라는 컴퓨터가 B라는 컴퓨터에게 데이터를 보내기 위해서 먼저 말을한다
B야!! 나 데이터 보낼꺼니까 준비해!!
그래서 어떤 특정한 선에다가 신호를 써서 보낸다.( 그럼 RTS가 1로 쭈욱~~ 들어온다 , 다른 예로는 수업중 교수님에게 질문 하려고 손 드는것! 그리고 교수님이 손 내리라고 하는것이 신호를 내리는 것(clear)!)
캐리어 센스 하면 2가지 중 하나이다. 이미 쓰고 있거나 아니면 쓰지 않고 있거나!
안 쓰고 있다는 것이 채널이 free 하다는 것이고, 쓰고 있으면 채널이 busy 하다는 것이다!
채널이 비면 CTS를 보내준다!
Trasmit gamming signal
한 100개서 통신을 하면 충돌이 많이 날 것인데, 이것을 정하는 기준이 되게 어렵다.(나중에 포스팅 하도록 하겠다)
컴퓨터 ABC가 있다. ABC가 다 데이터를 전송 하려고 한다. 그래서 ABC가 Carrier Sence 한다!(전송이 가능한지 듣는것!) 그리고 나서, 공기가 비어 있다고 생각하면 서로 보낼 수 있다고 생각한다 (Multi-Access) 그리고 A와 C가 데이터를 보낸다! 그럼 중간에 충돌이 발생할 것이지!(Collision Detection) 그럼 충돌이 난 사실을 누가 알고 있을까!?
정답은 아무도 모른다!
왜 그럴까!? 정답은 "충돌은 내가 말을 할 때 내 귀에도 다른 말이 들리면 충돌이다! "라는 말을 생각해 보자. 컴퓨터도 말을 하고 있지만, 아직 신호가 들어오지 않았습니다.B는 말은 안하고 있고 신호만 있습니다. C는 아직 말하고 있지만 A의 데이터가 도착하지 않았으니 충돌이 나지 않았다고 생각을 한다.
그런데 시간이 지나서 A의 데이터가 C로 도착하거나 C의 데이터가 A로 도착하면 충돌이 난 것을 알 수 있다.
그러고 나서 다른놈에게 도착하면 충돌이 난 것을 알고 Gamming signal을 보낸다. 그리고 생각합니다 " 나 말고도 숫자를 외친 애가 있구나 .. 조금 기다려야지"
이러면서 B가 어부지리로!!!!!!!!!!! 신호를 보냅니다.
우리 집에서 이런 일이 계속 발생한다.
만약 나를 괴롭히는 형이 지금 영화를 실시간 스트리밍으로 보고 있다고 생각하자.
그럼 우리는 무선랜에 파일 다운을 걸어버린다. 그럼 영화가 엄청 끊길 것이다 ㅋㅋㅋㅋㅋㅋ (데이터가 왔다가 멈췄다가 할 거기 때문에)
여기에서 저런 젬 신호가 왔다갔다 하면서 싸우는 것이기 때문이죠 ㅋㅋㅋ
이건 옛날에 누나가 인강들을때 저도 동영상 켜놓고 막 이럣던 기억이 있네여 ㅋㅋㅋ
포스팅 내용은 실시간으로 변경될 수 있습니다. 조금 맞지 않는 개념 혹은 틀린 개념이 있으면 언제든지 댓글 달아주세요!
포스팅이 너무 길어서 잘라서 포스팅 할 까 생각도 했지만, 한번에 다 읽으시는 분들도 계시니까ㅎㅎ
그래서 이번 포스팅은 가장 코어(core)적인 것만 작성해 보도록 하겠습니다.
OSI 7계층 종류.
1계층 : 물리계층
2계층 : 데이터 링크 계층
3계층 : 네트워크 계층
4계층 : 전송 계층
5계층 : 세션 계층
6계층 : 프리젠테이션 계층
7계층 : 응용계층(표현계층)
1~4계층은 TCP/IP의 4계층이라고도 부르며, 5~7계층은 개발자가 직접 개발(코딩)하는 부분입니다.
데이터 단위.(봉투단위)
1계층 - Bit ( 비트 )
2계층 - Frame ( 프레임 )
3계층 - Datagram ( 데이터그램 )
4계층 - Segment ( 세그먼트 )
각 계층의 주소지정.- 봉투에 주소를 작성한다.
2계층 - 물리 주소지정(MAC주소)
프레임이 네트워크 상에 서로 다른 시스템에 분배되어 진다면, 데이터링크 계층은 프레임의 송신자 그리고 또는 수신자를 지정하기 위해 프레임에 헤더를 더합니다. 만약 프레임이 송신자 네트워크가 아닌 다른 네트워크에 있는 시스템이라면, 수신자 주소는 다음 네트워크로 가도록 연결된 연결 장치의 주소가 된다.
3계층 - 논리 주소지정(IP주소)
데이터 링크 계층에 의해 구현된 물리 주소 지정은 내부적인 주소지정과 문제를 처리합니다. 만약 패킷이 네트워크의 범위를 벗어나면 발신지와 목적지를 구분하기 위한 또 다른 주소지정 시스템이 필요합니다. 네트워크 계층은 상위 계층으로부터 오는 패킷의 송신자와 수신자의 논리 주소를 포함하는 헤더를 더합니다.
4계층 - 서비스 지점 주소지정(Port 번호)
컴퓨터는 같은 시간의 여러 개의 프로그램(프로세스)을 실행 합니다. 이러한 이유 때문에, 발신지 대 목적지 전달은 하나의 컴퓨터에서 다음 컴퓨터까지 전달하는 것뿐만 아니라 한 컴퓨터상에 특정 프로세스(실행 중인 프로그램)에서 다른 컴퓨터에 있는 특정 프로세스(실행 중인 프로그램)까지 전달을 의미합니다. 그래서 전송 계층 헤더는 서비스 지점(service-point) 주소 (또는 포트(port) 주소)란 주소 유형을 포함합니다. 네트워크 계층은 정확한 컴퓨터에 각 패킷을 갖게 하지만 전송 계층은 컴퓨터상의 정확한 프로세스에게 전체 메시지를 갖게 한다.
OSI 7계층의 신뢰성을 보장하는 계층
4계층 - 전송 계층은 발신지 대 목적지 레벨에서 오류 제어와 흐름 제어를 통하여 순서대로 도착하는 것을 보장한다.
-> 경우에 따라서는 2계층에서도 재 전송을 하기도 합니다(LTE)
주소 작성.
4계층에서 보내는애, 받는 애의 포트번호를 작성한다.(프로세스 - 프로세스 통신이기 때문에)
