Reliable UDP (이하 RUDP)는 신뢰성을 갖는 UDP를 의미합니다.

일반적으로 TCP는 신뢰성을 갖는 대신 느리고, UDP는 신뢰성이 없고 빠르다고 알려져있죠.

여기에 또 하나의 특징은, TCP는 서버 (Listener)와, 클라이언트 (Connector) 관계가 성립한다는 점입니다.

즉, 서버건 클라이언트건 연결 관리가 필요하다는 것이죠.

RUDP의 필요성은, 주로 클라이언트 끼리의 통신에서 대두되었습니다.

우선 일반적인 클라이언트/서버 구조에서의 클라이언트 끼리의 통신은 서버를 경유해서 데이터를 전송함으로써 신뢰성을 갖추는데, UDP보다 느리고 서버에 부하를 주기 때문에 클라이언트 끼리의 통신에서도 TCP의 장점은 신뢰성과, UDP의 장점은 속도를 모두 갖춘 Reliable UDP가 등장하게 된 것이죠.

TCP는 한쪽이 서버가 되어서 대기 하고 있어야하지만, UDP는 그럴 필요가 없이 바로 통신이 가능하다는 점도 또 하나의 장점입니다.

보통 RUDP는 Relay Server와 연동되어서 구현이 되는데요, 모든 상황에서 UDP 통신이 가능한 것이 아니기 때문에, UDP 통신이 실패했을 때 신뢰성 갖춘 통신을 위해 Relay Server를 통한 데이터 전송을 해주기 위해서입니다.

우선 UDP가 Reliable 해지기 위한 방법부터 알아봅시다.

TCP가 UDP와 다른 점은 신뢰성이 있다고 얘기했었죠? TCP가 신뢰성을 갖추고 있는 이유를 먼저 얘기해보겠습니다.

1. 데이터의 순서를 보장해줍니다. 보낸 순서와 받는 순서가 일치하게 해준다는 의미입니다.
2. 데이터의 도착을 보장해줍니다. 보낸 데이터가 반드시 도착한다는 것을 보장해준다는 의미입니다.
3. 데이터의 무결성을 보장해줍니다. 즉, 보낸 데이터와 받는 데이터가 일치 하다는 것을 보장한다는 의미입니다.

위의 세가지 조건을 만족하기에 TCP가 신뢰성을 갖추고 있다고 말하는 것이고, RUDP도 마찬가지로 위 세가지 조건을 UDP를 통해 만족하도록 구현함으로써 신뢰성을 갖게 되는 것이죠.

순서를 보장하는 방법은 패킷에 번호를 붙이고, 번호순서대로 패킷이 도착할때까지 기다렸다가 패킷이 모두 모이면 그때 패킷을 풀면됩니다.

도착을 보장하는 방법은 패킷에 번호를 붙이고, 해당 번호의 패킷이 도착할때까지 재전송하면 됩니다.

보내는 입장에서 재전송을 하는 이유는, UDP이기에 받는 입장에서는 자신에게 보내려는 패킷이 있었는지 알 방법이 없기 때문이죠.

무결성을 보장하는 방법은 체크섬을 통해서, 데이터가 손실되지 않았는지 검증합니다.

RUDP사용시 주의사항은, UDP로 연결을 시도하는 중에도 릴레이 서버를 통한 패킷 전달은 지속적으로 이루어 져야 한다는 점입니다.

그리고 UDP연결이 성공했을 때 UDP를 통한 송신을 시작해야 합니다.

UDP 송수신 중에는 연결 유지를 위해 일정 시간 간격으로 HeartBeat 패킷을 보내고, 일정 시간동안 해당 패킷이 도착하지 않는다면  UDP전송이 다시금 불가능해진 것으로 판단하여, 릴레이 서버를 이용하도록 하면서 지금껏 전송 확인이 안된 패킷들을 릴레이를 통해 전달하면 됩니다. 이렇게 해야 패킷의 지연은 있을 수 있으나 패킷의 소실은 발생하지 않습니다.

ref : 

https://elky.tistory.com/258

종합 레코드

 ref : https://support.google.com/domains/answer/6069273?hl=ko&ref_topic=3251230

Code, test, and deploy together with GitLab open source git repo management software

Code, test & deploy with GitLab. Everyone can contribute!

gitlab.com

깃랩에서는 비공개 레포지토리를 무료로 무제한 사용할 수 있습니다. (10명 이하일 경우)

한푼이라도 아껴야만 하는 스타트업에겐 외부 개발인력이나 팀 내에서

무료로 소스를 관리할 수 있는 유용한 서비스라고 볼 수 있겠습니다.

훌륭한 이슈트래커와,

아래와 같은 간단한 개발 업무용 도구도 제공합니다.

이슈트래커 및 협업시 칸반보드로 활용할 수도 있습니다.

마일스톤도 관리할 수 있고요 ㅎㅎ

이러한 협업 도구는 생긴지 얼마 되지 않은 것으로 기억하고 있습니다.

깃허브만 알고 계시던 분들 중,

간단한 서비스 개발을 위한 저렴한 레포지토리를 원하시는 경우

새로운 선택지로  고민해 볼만한 옵션인 것 같습니다.

ref : https://m.blog.naver.com/PostView.nhn?blogId=soulic_&logNo=221019778273&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F

1 윈도우 - 마우스 오른쪽 클릭 - 제어판

2 프로그램 클릭

3 '프로그램 및 기능'에서 windows 기능 켜기/끄기 클릭

5 텔넷 클라이언트 체크!

6 변경 내용 적용 - 확인 후 닫기

7 cmd창(ctrl+R -> cmd)에서 'telnet' 명령어를 치면 이렇게 뜬답니다!

ref : https://opentutorials.org/module/2160/12506

이글은 Quora에 올라온 “What’s the difference between sharding and partition?“글의 질문과 모자이크 CTO가 답변한 내용을 번역한 글입니다.

샤딩(sharding)과 파티셔닝(partitioning)의 차이가 무엇인가?

분산 데이터베이스 시스템에서 샤딩과 파티셔닝이라는 단어를 종종 듣는다. 하지만 그들의 차이점을 잘 모르겠다. 그래서 이것들을 위키에서 검색해보았지만 여전히 혼란스럽다. 약간의 예제를 줄 수 있을까?

Tony Bako, Mosaic의 CTO의 답변

파티셔닝이란 퍼포먼스(performance), 가용성(availability) 또는 정비용이성(maintainability)를 목적으로 당신의 논리적인 데이터 엘리먼트들을 다수의 엔티티(table)로 쪼개는 행위를 뜻하는 일반적인 용어이다.

샤딩은 수평 파티셔닝(horizontal partitioning)과 동일하다. 데이터베이스를 샤딩하게 되면 기존에 하나로 구성될 스키마를 다수의 복제본으로 구성하고 각각의 샤드에 어떤 데이터가 저장될지를 샤드키를 기준으로 분리한다. 예를 들면, 나는 고객의 데이터베이스를 CustomerId를 샤드키로 사용하여 샤딩하기로 하였다. 0 ~ 10000 번 고객의 정보는 하나의 샤드에 저장하고 10001 ~ 20000 번 고객의 정보는 다른 샤드에 저장하기로 하였다. DBA는 데이터 엑세스 패턴과 저장 공간 이슈(로드의 적절한 분산 , 데이터의 균등한 저장)를 고려하여 적절한 샤드키를 결정하게 된다.

수직 파티셔닝(vertical partitioning)은 하나의 엔티티에 저장된 데이터들을 다수의 엔티티들로 분리하는것을 말한다. (마찬가지로 공간이나 퍼포먼스의 이유로) 예를 들면, 한 고객은 하나의 청구 주소를 가지고 있을 수 있다. 그러나 나는 데이터의 유연성을 위해 다른 데이터베이스로 정보를 이동하거나 보안의 이슈등을 이유로 CustomerId를 참조하도록 하고 청구 주소 정보를 다른 테이블로 분리할 수 있다.

Vertical Partitioning

요약하면 파티셔닝은 퍼포먼스, 가용성, 정비용이성등의 목적을 위해 논리적인 엔티티들을 다른 물리적인 엔티티들로 나누는것을 의미하는 일반적인 용어이다. 수평 파티셔닝 또는 샤딩은 스키마 복제 후 샤드키를 기준으로 데이터를 나누는것을 말한다. 수직 파티셔닝은 스키마를 나누고 데이터가 따라 옮겨가는것을 말한다.

ref : http://theeye.pe.kr/archives/1917

on premise 사내 직접 설치

온프레미스(On-premise)란 소프트웨어 등 솔루션을 클라우드 같이 원격 환경이 아닌 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식을 말합니다. 온프레미스는 클라우드 컴퓨팅 기술이 나오기 전까지 기업 인프라 구축의 일반적인 방식이었기 때문에 이전 또는 전통적인 이라는 단어와 함께 사용됩니다. 

일반적으로 온프레미스 시스템을 구축하는데 시간이 수개월 이상 걸렸고 비용 또한 많이 들어, 퍼블릭 클라우드가 나올 당시만 해도 온프레미스 환경이 금방이라도 모두 사라질 것 같았습니다. 하지만 보안 적인 이유로 비즈니스에 중요하고 보안이 필요한 서비스와 데이터는 온프레미스 환경에서, 덜 중요한 것은 퍼블릭 클라우드 환경을 사용하는 하이브리드 IT 인프라가 대세를 이루고 있습니다. 

온프레미스 vs 오프프레미스

ref : http://mickeyh-words.blogspot.kr/2014/01/vs.html

ref : http://www.dt.co.kr/contents.html?article_no=2017012602102269041001

[소캣(Socket)]

소켓(socket)은 통신의 극점(EndPoint)를 뜻한다. 두 프로세스가 네트워크 상에서 통신을 하려면 양 프로세스마다 하나씩 총 두 개의 소켓이 필요하다. 클라이언트 프로세스가 연결을 요청하면 호스트 컴퓨터가 포트 번호를 부여한다. 이때 포트 번호는 1024(0~1024는 시스템 예약)보다 큰 임의의 정수가 사용된다. 모든 연결은 유일 해야 한다.

소켓을 이용한 통신은 분산된 프로세스들 간에 널리 사용되고 효율적이기는 하지만 너무 저수준이다. 우선 소켓은 쓰레드들 간에 구조화되지 않은 바이트 스트림만을

통신하도록 하기 때문이다. 이러한 원시적인 바이트 스트림 자료를 구조화 하여 해석하는 것은 클아이언트와 서버의 주요 작업이 된다.

소켓이란 무엇인가?

소켓 통신

일반적으로 서버는 특정 포트가 바인딩된 소켓를 가지고 특정 컴퓨터 위에서 돌아갑니다.
해당 서버는 클라이언트의 연결 요청을 소켓을 통해 리스닝하면서 그냥 기다릴 뿐이죠.

클라이언트는 서버가 떠 있는 머신의 호스트네임과 서버가 리스닝하고 있는 포트 번호를 알고 있습니다.
따라서 클라이언트는 이 호스트 네임과 포트를 통해서 서버와 연결을 시도하게 됩니다.
또한 클라이언트는 서버 상대로 자신을 식별시켜주기 위해서 연결동안 사용될 로컬 포트에 바인딩됩니다.
이 포트 바인딩 작업은 보통 시스템에 의해서 이뤄집니다.

5connect

만약에 모든 게 순조롭게 이뤄진다면 서버는 연결을 수락하게 됩니다.
수락하자마자, 서버는 동일한 로컬 포트에 바인딩된 새로운 소켓을 얻게 되며 클라이언트의 주소와 포트로 세팅된 리모트 엔드 포인트를 가지게 됩니다.
서버가 별개의 새로운 소켓이 필요한 이유는 연결된 클라이언트의 요청을 처리하면서, 동시에 기존의 소켓을 통해서는 지속적으로 연결 요청을 받아야 하기 때문입니다.

6connect

클라이언트 입장에서는 만약에 연결이 수락되면 소켓은 성공적으로 생성되며 클라이언트는 서버와 통신하기 위해서 소켓을 사용할 수 있게됩니다.

클라이언트와 서버는 이제 소켓에 데이터를 쓰거나 읽음으로써 통신할 수가 있게됩니다.

소켓의 정의

소켓은 네트워크 상에서 돌아가는 두 개의 프로그램 간 양방향 통신의 하나의 엔트 포인트입니다.
소켓은 포트 번호에 바인딩되어 TCP 레이어에서 데이터가 전달되야하는 어플리케이션을 식별할 수 있게 합니다.

엔드 포인트란?

여기서 엔드 포인트라 함은 아이피 주소와 포트 번호의 조합을 의미합니다.
모든 TCP 연결은 2개의 앤드 포인트로 유일하게 식별되어질 수 있습니다.
따라서 클라이언트와 서버 간 여러 개의 연결이 맺어질 수 있습니다.

Socket 클래스

자바 플랫폼에서 java.net 패키지는 네트워크 상에서 두개의 프로그램 간 양방향 통신에서 한쪽 지점을 구현하는 Socket 클래스를 제공합니다.
Socket 클래스는 특정 시스템의 세부사항은 감추면서 플랫폼 독립적인 구현의 최상단에 위치합니다.
네이트브 코드에 의존하는 대신에 java.net.Socket 클래스를 이용해서 플랫폼 독립적인 방식으로 네트워크 상에서 통신을 할 수 있습니다.

추가적으로 java.net 패키지는 서버가 클라이언트로 부터 연결을 리스팅하고 수락하는데 사용되는 소켓을 구현하는 ServerSocket 클래스도 포함합니다. 본 튜토리얼에서는 Socket과 ServerSocket 클래스를 어떻게 사용하는지 살펴볼 것입니다.

Web 통신

혹시 Web 통신을 하려고 한다면, URL 클래스와 관련 클래스(URLConnection, URLEncoder)들이 아마도 본 소켓 클래스보다 더 적당할 것입니다. 사실상, URL은 Web에 대한 상대적으로 고수준의 연결이며 기저 구현으로 소켓을 사용합니다.
URL을 통한 Web 통신 관련해서는 해당 튜토리얼을 참고바랍니다.

ref : http://sqlmvp.tistory.com/169

ref :http://www.daleseo.com/what-is-a-socket/

HTTP Referer는 HTTP 헤더값으로서 웹 브라우저에서 생성하는 데이터입니다. 

http referer : 현재 페이지로 오기 전의페이지주소값이 담겨있는 환경변수

HTTP 환경변수의 HTTP_REFERER를 이용해서 어느정도 확인할 수 있습니다. 
대부분의 웹사이트 접속통계를 내주는 곳에서도 이런 방법으로 처리를 합니다. 

각 언어별로 HTTP_REFERER를 확인하는 방법은 아래와 같습니다. 
ASP => Request.ServerVariables("HTTP_REFERER") 
PHP => $_SERVER['HTTP_REFERER'] 
JSP => request.getHeader("REFERER") 

HTTP_REFERER의 값의 유무와 각 웹서버의 로그파일을 이용해서 
어떻게 방문했는지를 추출할 수 있습니다. 
1. 주소창에 주소를 입력해서 들어오는 경우 
- HTTP_REFERER의 값이 없음 
2. '즐겨찾기'를 이용해서 들어오는 경우(IE의 경우) 
- HTTP_REFERER의 값이 없음 
- 로그파일에 ..../favicon.ico로그가 먼저 남는다. 
- 이는 IE가 즐겨찾기를 눌러서 사이트를 방문할 경우 
favicon.ico 요청을 하고, 해당 URL의 요청을 하기때문입니다. 
3. 링크를 통해서 들어오는 경우. 
- HTTP_REFERER에 이전 URL정보가 들어있음. 
- e.g) http://search.empas.com/search/all.html?s=&f=&z=A&q=검색어 

이렇게 3가지 패턴으로 어느정도 확인을 할 수가 있습니다. 

추가적으로 어떤 검색엔진이나 사이트에서 링크를 통해서 들어왔는지는 
3번의 URL의 주소를 분석해서 알수 있습니다. 

배너광고나 검색엔진등에 등록했을때 유용하게 사용할 수 있습니다. 

ref : https://blog.naver.com/sungs6031/40011125523

서브도메인은 무엇입니까?

ref :https://kr.godaddy.com/help/what-is-a-subdomain-296

정적 웹 페이지 (Static Web Page)

• 서버(웹 서버, Web Server)에 미리 저장된 파일(HTML 파일, 이미지, JavaScript 파일 등)이 그대로 전달되는 웹 페이지
• 서버는 사용자가 요청(Request)에 해당하는 저장된 웹 페이지를 보냄
• 사용자는 서버에 저장된 데이터가 변경되지 않는 한 고정된 웹 페이지를 보게 됨

동적 웹 페이지 (Dynamic Web Page)

• 서버(웹 서버, Web Server)에 있는 데이터들을 스크립트에 의해 가공처리한 후 생성되어 전달되는 웹 페이지
• 서버는 사용자의 요청(Request)을 해석하여 데이터를 가공한 후 생성됭되는 웹 페이지를 보냄
• 사용자는 상황, 시간, 요청 등에 따라 달라지는 웹 페이지를 보게 됨

 인터넷을 이용하면서 보게되는 웹 페이지는 크게 두가지로 나눌 수 있습니다. 하나는 정적 웹 페이지이고 다른 하나는 동적 웹 페이지입니다.
정적 웹 페이지는 마치 컴퓨터에서 저장된 텍스트 파일을 메모장으로 열어보듯이 저장된 그대로 보는 것이며,
동적 웹 페이지는 그런 내용들이 다른 변수들에 의해서 변경되어 보여집니다. 가장 큰 차이는 사용자가 받아보는
웹 페이지가 동적으로 변하는가 아닌가에 있습니다.

 우리가 보는 대부분의 웹 페이지는 동적 웹 페이지라 할 수 있습니다. 커뮤니티 사이트에서 게시글을 본다거나, 뉴스 사이트에 올라오는 뉴스를
 본다거나, 포털 사이트 같은 곳에서 웹툰을 본다거나, 이런 웹 페이지는 사용자의 요청에 따라서 원하는 페이지를 동적으로 생성하여 보내주는
것입니다. 모두 동적 웹 페이지죠. 2000년대 초만 하더라도 정적 웹 페이지가 꽤 많았지만, 웹 서비스의 발전에 따라, 사용자 및 서비스 제공자의
요구를 충족시키기 위해, 현재는 대부분(모두가 아님) 동적 웹 페이지로 구성되어 있습니다. 서비스 제공자 입장에서, 예를 들어 쇼핑몰 운영자라
가정할 때, 정적인 웹 페이지로만 웹 페이지를 구성하게 되면 상품을 등록하거나 제거할 때, 회원관리할 때, 상품 재고 관리할 때 등 그때마다 정적
웹 페이지를 제작해줘야 하지만, 동적 웹 페이지로 웹 사이트를 구축하여 상품등록 및 관리, 회원가입 등에 해당하는 스크립트만 작성하고 자동으로
페이지가 생성되게 해주면 사이트 관리 비용이 절감되게 되는 것입니다.

 사용자 입장에서는 서버에서 처리된 웹 페이지를 전달받기 때문에 정적 웹 페이지와 동적 웹 페이지를 구분지을 필요가 없습니다.
결국 전달받는 웹 페이지는 HTML로 이루어진 웹 페이지기 때문이죠(JavaScript 등을 이용해서 클라이언트 측에서 동적으로 변하는 웹페이지도
 있습니다만 여기에서 설명하는 부분은 서버 측 기준이고, 스크립트 역시 정적인 데이터라 분류했기 때문에 여기에서 다루지 않습니다). 하지만
웹 사이트를 구축할려는 입장에서는 이런 부분에 대해서 최소한 개념적으로라도 이해를 해야한다고 생각합니다.

정적 웹 페이지 vs 동적 웹 페이지

• 정적 웹 페이지 장점
  • 빠르다 : 요청에 대한 파일만 전송하면 되기 때문에 추가적인 작업이 없음
  • 비용이 적다 : 마찬가지로 웹 서버만 구축하면 됨
• 정적 웹 페이지 단점
  • 서비스가 한정적이다 : 저장된 정보만 보여줄 수 있음
  • 관리가 힘들다 : 추가/수정/삭제의 작업 모두 수동
• 동적 웹 페이지 장점
  • 서비스가 다양하다 : 다양한 정보를 조합하여 동적으로 생성하여 제공 가능
  • 관리가 쉽다 : 웹 사이트 구조에 따라서 추가/수정/삭제 등의 작업이 용이
• 동적 웹 페이지 단점
  • 상대적으로 느리다 : 사용자에게 웹 페이지를 전달하기 전에 처리하는 작업이 필요
  • 추가 비용이 든다 : 웹 서버외에 추가적으로 처리를 위한 어플리케이션 서버(Web Application Server)가 필요

 동적 웹 사이트는 정적 웹 사이트와는 달리 서버 내부에서 추가적인 작업이 필요하기 때문에 서버 내부에 그런 작업들을 처리하기 위한
모듈 같은 것이 필요합니다. 설치형 사이트인 워드프레스의 경우를 보더라도 PHP와 MySQL를 요구합니다. 스크립트 처리기(PHP)와
데이터베이스(MySQL)입니다. 따라서 서버를 구성하실 때 해당 모듈을 설치해야 하며, 웹 호스팅을 이용할 때도 해당 모듈들을 제공하는
서비스를 선택해야합니다(대부분의 웹 호스팅은 PHP와 MySQL를 제공합니다. 하지만 요구 버전 등이 있으니 확인하셔야 합니다).
이런 모듈들은 서버의 자원(CPU, 메모리 등)을 이용하기 때문에 비용에 속합니다.이런 모듈들을 이용해서 동적 웹 페이지를 생성한다는 것
자체가 당연히 바로 전송하는 것보다 느립니다. 이런 부분도 비용에 해당합니다. 하지만 웹 사이트 구축과 운영/관리 측면에서 보면,
구조화된 웹사이트 구축과 관리의 용이성 때문에 전체적인 비용이 절감된다고 볼 수 있습니다. 정적 웹 페이지는 각각 독립되어 있기
때문에 같은 코드가 포함된다 해도 각각 따로 저장되어야 하지만(iframe 등의 태그 이용 제외), 동적 웹 페이지는 중복 코드는 하나의 파일로
만들어서 스크립트로 불러오기가 가능합니다. 따라서 구조화된 웹 사이트를 구축할 수 있으며, 수정 또한 정적 웹 페이지는 각각 페이지를
수정해줘야 하지만, 동적 웹 페이지는 공통된 부분 한번만 수정을 해서 전체 웹 사이트가 수정되는 효과를 가져올 수 있습니다.

 그렇다고 모두 동적 웹 페이지로 구성하고 정적 웹 페이지를 전혀 사용하지 않는 것은 아닙니다. 자주 변경되지 않은 페이지(About과 같은)의
 경우는 굳이 동적 웹 페이지로 만들 필요는 없습니다. 그리고 최근에는 정적 웹 페이지의 적은 비용이라는 장점을 이용하는 방법도
많이 사용됩니다. 정적 웹 페이지 생성기를 통해서 정적 웹 페이지로만 이루어진 블로그 등이 있습니다. 자신의 웹 사이트의 성격에 맞게,
각각 페이지 특성에 맞게 정적과 동적 웹 페이지를 적절하게 섞어서 사용하시면 되겠습니다.

ref : http://titus94.tistory.com/4

TCP/IP 네트웍에서 포트 번호는, 들어오는 트래픽을 컴퓨터 내에서 실행되고 있는 적절한 프로그램에 분배시키기 위해 할당되는 숫자를 말한다. 이것은 물리적인 플러그나 소켓이 아니며, 다만 논리적인 할당일 뿐이다

# 프로그래밍에서, 포트는 "논리적인 접속장소"이며, 특히 인터넷 프로토콜인 TCP/IP를 사용할 때에는 클라이언트 프로그램이 네트웍 상의 특정 서버 프로그램을 지정하는 방법으로 사용된다. 웹 프로토콜인 HTTP와 같이, TCP/IP의 상위 프로토콜을 사용하는 응용프로그램에서는 미리 지정된 포트번호 들을 가지고 있다. 이런 것들은 IANA에 의해 지정되었으며, "잘 알려진 포트들"이라고 불린다. 다른 응용프로그램 프로세스들은 매번 접속할 때마다 포트번호가 동적으로 부여된다. 서버 프로그램이 처음 시작되면, 지정된 포트번호로 바인드된다. 그 서버를 사용하려는 모든 클라이언트 프로그램들은 지정된 포트번호에 바인드해야만 한다. 

바인드가 되면  두개의 컴퓨터간 네트워크를 이용한 통신시 발신지 컴퓨터에서 출발한 사용자 데이터(패킷)는 TCP/IP의 각 계층을 거치면서 최종적으로 목적지 주소(IP)를 가지고 있는 컴퓨터에 도착하게 됩니다. 패킷을 수신한 컴퓨터는 전송시에 사용되었던 주소필드를 제거하고, 패킷 안에 있는 데이터만을 응용프로그램에 넘겨줍니다. 

결국 데이터를 넘겨줄 컴퓨터에는 FTP, Mail, Telnet, SSH, Web 등 다양한 종류의 응용프로그램이 기동하고 있을 것입니다. 수신측 컴퓨터가 인터넷 계층에서 패킷을 수신한 후 응용층으로 데이터를 전달하려고 할 때, 컴퓨터내에 기동중인 많은 응용프로그램들 중 누구에게 데이터를 전달해야 하는지 어떻게 구분할까요? 이러한 문제를 해결하기 위해서 운영체제는 응용프로그램의 논리적인 주소인 Port 번호라는 것을 이용합니다. 즉 각각의 응용프로그램 (서비스)에 유일한 논리적 주소인 Port 번호를 할당하여서, 전송계층에서 응용프로그램을 구분할 수 있도록 하고 있습니다.  


포트번호는 0부터 65536 이다. 포트번호 0부터 1024까지는 어떤 특권을 가진 서비스에 의해 사용될 수 있도록 예약되어 있다. HTTP 서비스를 위해서는 대개 80번 포트가 지정되는데, URL에 이를 적을 필요는 없다.

# 하드웨어적인 경우, 컴퓨터나 통신장비에서, 포트는 일반적으로 다른 장치에 물리적으로 접속되는 특정한 부위를 말하며, 대개 소켓이나 플러그 등의 형태로 되어 있다. 일반적으로 PC에는 하나 이상의 직렬 포트와 한 개의 병렬 포트가 제공된다. 직렬 포트는 한번에 한 비트씩 모뎀과 같은 주변장치로 전송하는 직렬 전송을 지원하며, 병렬 포트는 한번에 여러 비트씩 프린터와 같은 주변 장치로 전송할 수 있는 병렬 전송을 지원한다.

#  Port 번호는 16 비트 크기의 정수로 되어 있어 1부터 65535번까지를 사용할 수 있으며, 자주 사용되는 표준 인터넷 서비스에 대해서는 그 번호가 미리 할당(약속)되어져 있습니다. 이러한 것을 잘 알려진 포트(Well-Known Port)라 하며, 관리는 국제 인터넷
할당번호 관리기관인 IANA(Internet Assigned Numbers Authority)에서 하고 있습니다. 
 
 예를 들면 FTP는 21번, Telnet 는 23번, SMTP(mail)는 25번, HTTP 는 80번 등으로 약속되어져 있습니다. 보통은 이러한 Well-Known 포트를 각 운영체제별로 "Services"라는 파일로 저장하고 있습니다. IANA에 의하면 보통 1번부터 1023까지는 Well-Known Port 영역으로 예약되어 있으며,

그 이상은 어플리케이션 서비스를 위해 할당되거나, 혹은 그때그때 임시로 할당되는 Port 번호들입니다.

Port 번호의 저장  
Unix의 경우 : /etc/services
Windows의 경우 : C:\windows\services
Windows NT의 경우 : C:\winnt\system32\dirvers\etc\services  파일로 저장합니다. 

호스트 (네트워크)

포트 (컴퓨터 네트워킹)

인터넷 프로토콜 스위트에서 포트(port)는 운영 체제 통신의 종단점이다. 이 용어는 하드웨어 장치에도 사용되지만, 소프트웨어에서는 네트워크 서비스나 특정 프로세스를 식별하는 논리 단위이다. 주로 포트를 사용하는 프로토콜은 전송 계층 프로토콜이라 하며, 예를 들어 전송 제어 프로토콜(TCP)와 사용자 데이터그램 프로토콜(UDP)가 있다. 각 포트는 번호로 구별되며 이 번호를 포트 번호라고 한다. 포트 번호는 IP 주소와 함께 쓰여 해당하는 프로토콜에 의해 사용된다.

사용 및 표기

URI 문법에 의해서 사용 및 표기할 수 있으며, IP 주소와 함께 URL을 표기하는 예는 다음과 같다.

ftp://000.000.000.000:21

위 표기에서 ftp://는 URI 스킴과 구분 기호를, 000.000.000.000은 IP 주소를 의미하며 : 다음의 21은 포트 번호를 의미한다.

포트 번호를 생략 가능한 경우가 있는데 예를 들면,

http://000.000.000.000

위와 같은 같은 월드 와이드 웹 URL은 기본적으로 80번 포트를 사용하므로 웹 브라우저는 자동적으로 이를 다음과 같은 의미로 처리한다.

http://000.000.000.000:80

일반적인 포트 번호

 이 부분의 본문은 TCP/UDP의 포트 목록입니다.

포트 번호는 크게 세 종류로 구분된다.

• 0번 ~ 1023번: 잘 알려진 포트 (well-known port)
• 1024번 ~ 49151번: 등록된 포트 (registered port)
• 49152번 ~ 65535번: 동적 포트 (dynamic port)

잘 알려진 포트 번호의 대표적 예는 다음과 같다.

• 20 : FTP(data)
• 21 : FTP(제어)
• 22 : SSH
• 23 : 텔넷
• 53 : DNS
• 80 : 월드 와이드 웹 HTTP
• 119 : NNTP
• 443 : TLS/SSL 방식의 HTTP

ref :

http://memoweb.tistory.com/entry/%ED%8F%AC%ED%8A%B8%EC%9D%98-%EA%B0%9C%EB%85%90%EA%B3%BC-%EB%B3%B8%EC%A7%88-port

https://ko.wikipedia.org/wiki/%ED%98%B8%EC%8A%A4%ED%8A%B8_(%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC)

https://ko.wikipedia.org/wiki/%ED%8F%AC%ED%8A%B8_(%EC%BB%B4%ED%93%A8%ED%84%B0_%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%82%B9)

74
1974
750
-114
-273

3.14
-2.718

1e4
2.5e12
3.4e+4
4.56e-8
5.67E+10
6.78E-5

"1234"
"Love"
"O-matic"
"한글"
"\"JSON\""

1  [10, {"v": 20}, [30, "마흔"]]

 {"name2": 50, "name3": "값3", "name1": true}

1  {
2     "이름": "홍길동",
3     "나이": 25,
4     "성별": "여",
5     "주소": "서울특별시 양천구 목동",
6     "특기": ["농구", "도술"],
7     "가족관계": {"#": 2, "아버지": "홍판서", "어머니": "춘섬"},
8     "회사": "경기 수원시 팔달구 우만동"
9  }

JSON 데이터 교환 포맷 : http://www.json.org/

JSON 포멧터 :  https://jsonformatter.org/

JSON 검사기 :  https://codebeautify.org/jsonvalidator

ref : https://ko.wikipedia.org/wiki/JSON

인터넷을 통해 서버와 통신하고 있는 클라이언트의 컴퓨터 네트워크 다이어그램.

서버 사이드(server-side)란 네트워크의 한 방식인 클라이언트-서버 구조의 서버 쪽에서 행해지는 처리를 말한다.

예시

• HTTP 통신에 있어서 브라우저의 주요 기능 중 하나는 서버에서 HTML 문서를 수신하는 것인데, 브라우저에서 요청한 HTML 문서가 PHP 등의 서버 사이드 스크립트 언어를 포함하고 있으면 서버 쪽에서 이 부분을 처리하여 결과를 브라우저에 송신하게 된다.
  
  (여기서 브라우저를 클라이언트로 이해 하면 됨)
  
  

• MMORPG(대규모 다중 사용자 온라인 롤플레잉 게임)에서도 클라이언트-서버 구조가 사용된다. 대부분의 게임에서는 게임 캐릭터 정보와 게임 아이템 정보의 위조를 방지하기 위해 이를 서버 사이드로 처리한다.^[1]

데이터를 서버 사이드로 처리할 경우의 장단점

(클라이언트 사이드로 처리할 때와 비교하여)

• 장점: 서버 관리자의 입장에서, 데이터 위조의 가능성을 줄일 수 있다. 서버 쪽의 데이터가 확실한 진위이며 클라이언트 쪽에서 위조해서는 안 되는 민감한 데이터의 경우 서버 사이드로 처리해야 한다. 예로 인터넷 뱅킹의 이체 관련 처리나 MMORPG의 게임 아이템 관련 처리에서는 클라이언트 사이드 처리를 최소화해야 한다. 한편 클라이언트 사용자의 입장에서는 클라이언트 컴퓨터의 처리 부담이 줄어든다.
  
  

• 단점: 서버 관리자의 입장에서, 서버의 처리 부담이 커져 결과적으로 서버 비용이 늘어날 수 있다.
  
  

클라이언트 사이드(client-side)란 네트워크의 한 방식인 클라이언트-서버 구조의 클라이언트 쪽에서 행해지는 처리를 말한다.

예시[편집]

• HTTP 통신에 있어서 브라우저의 주요 기능 중 하나는 서버에서 수신한 HTML 문서를 해석하여 화면에 표시해 주는 것인데, HTML 문서가 동적인 부분을 갖고 있지 않다면 문서 수신이 끝나고부터는 서버와 교신하지 않고 브라우저가 클라이언트 사이드에서 처리하여 화면에 내용을 표시한다.

• MMORPG(대규모 다중 사용자 온라인 롤플레잉 게임)에서도 클라이언트-서버 구조가 사용된다. 대부분의 MMORPG는 화려한 그래픽 효과를 사용하는데 이를 위해서는 많은 연산이 필요하며 이러한 연산을 서버 쪽에서 모두 부담할 수 없으므로 그래픽 처리나 소리 처리의 대부분을 클라이언트 사이드로 처리한다.

데이터를 클라이언트 사이드로 처리할 경우의 장단점[편집]

(서버 사이드로 처리할 때와 비교하여)

• 장점
  • 서버 관리자의 입장에서, 서버의 처리 부담을 줄여서 결과적으로 서버 비용을 줄일 수 있다.
  • 처리하는 데이터가 보안에 민감한 경우, 클라이언트 내에서 처리가 가능한 부분에 대해서는 통신에 대비하여 암호화할 필요가 없으므로 암호화 소요가 줄어든다.
• 단점
  • 서버 관리자의 입장에서, 클라이언트 사이드에서 처리한 결과를 되받아야 하는 경우, 결과의 진위성을 알기 어렵다. 반대로 말하면 클라이언트 쪽에서 데이터를 위조하기 쉽다. 따라서 서버 쪽의 데이터가 확실한 진위이며 클라이언트 쪽에서 위조해서는 안 되는 민감한 데이터의 경우 서버 사이드로 처리해야 한다. 예로 인터넷 뱅킹의 이체 관련 처리나 위의 MMORPG의 게임 아이템 관련 처리에서는 클라이언트 사이드 처리를 최소화해야 한다.
  • 클라이언트 사용자의 입장에서, 클라이언트 컴퓨터의 처리 부담이 많아진다.

ref : https://ko.wikipedia.org/wiki/%EC%84%9C%EB%B2%84_%EC%82%AC%EC%9D%B4%EB%93%9C

ref : https://ko.wikipedia.org/wiki/%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8_%EC%82%AC%EC%9D%B4%EB%93%9C

ASP.NET의 정의

 

 

 

ASP.NET은 동적 웹 사이트(웹 응용 프로그램)를 만들기 위한 마이크로소프트의 웹 개발 기술이에요.

 

다른 웹 개발기술 언어인 ASP, PHP, JSP는

웹 스크립트 언어(Web Script Language)라고도 불러요.

하지만, ASP.NET은 웹 스크립트 언어라고 부르지 않습니다~

웹 개발 기술이라고 하는 것이 가장 정확하죠!

 

ASP.NET 버전은 다음과 같이 변화되었어요.
ASP.NET 1.0(2000년) → ASP.NET 1.1(2003년) → ASP.NET 2.0 (2005년)

 

 

 

 

여기서 잠깐!

다른 언어들과 달리 ASP.NET을 웹 개발 기술이라고 부르는 이유는?

 

웹기술은 로그인의 처리에서 처럼,

웹서버에서 내부 사용되는 로직을 개발하고 동작되게 해주는 프로그래밍언어를 말해요.

ASP.NET, JSP, PHP, ASP, Perl 등을 모두 웹 기술이라고 할 수 있어요.

또한 웹 스크립트 언어라고도 부를 수 있어요.

 

ASP, JSP, PHP, Perl 등은 그 이름 자체를 스크립트 언어라도고 지칭할 수 있지요.

하지만 ASP.NET 은 언어라고 할 수 없는 것이

ASP.NET을 구현할 수 있는 언어가 C#, VB, J#, C++ 등으로 나뉘어지기 때문에

ASP.NET은 웹 개발 기술이라고만 부릅니다.

ref : http://cafe.naver.com/dbgmlzkdlqk/3036

[출처] ASP.NET의 정의 / ASP.NET이란? / 웹 개발 기술 [KH정보교육원] (당신의 꿈을 이룰 KH 정보교육원입니다.) |작성자 보물지도

서버-클라이언트 구준

 클라이언트, 서버 나누는 기준 : 웹서버가 설치 되어 있다면 웹서버, 웹 브라우저로 접근한다면 클라이언트


.net 구조

.net 프레임 워크는 마치 자바의 virtual machine 과 유사한 형태로 여기 저기 플랫폼에서 돌아갈 수 있는 기본 환경을 제공을 목표로하며
닷넷 프레임 워크가 있다는 가정하네 C++, C# , VB, JSCRIPT 등이 돌아 갈 수 있게 되고 이것들을 .NET 언어라 하며 어떤 언어이든 간에
공통언어명세(CLS)에 맞게 만들어져있다면 이 언어들은 닷넷 환경에 서 돌아 가는 요구 조건을 갖췄다고 할 수 있다
또한 그림에서 볼 수있듯이 ASP.NET 이 .net framework 안에 들어 가있다는 것은 ASP.NET이 프로그램 랭귀지가 아니고
위에서 설명한것과 마찬가지로 개발기술 이라 한다, 또한 ASP.NET, ADO.NET, CLR 등등이 .net framework 의 구성요소가 된다

ASP.NET의 정의

ASP.NET은 동적 웹 사이트(웹 응용 프로그램)을 만들기 위한 마이크로소프트의 웹 개발 기술이다. 다른 웹 개발기술인 ASP, PHP, JSP는 웹 스크립트 언어(Web Script Language)라고도 부른다. 하지만, ASP.NET은 웹 스크립트 언어라고 부르지 않는다. 웹 개발 기술이라고 하는 것이 가장 정확하다. 이유는 차후에 설명한다.

ASP.NET 버전은 다음과 같이 변화되었다.
ASP.NET 1.0(2000년) → ASP.NET 1.1(2003년) → ASP.NET 2.0 (2005년)

ASP.NET은 .NET Framework에서만 동작한다. ASP.NET 1.X는 .NET Framework 1.1에서 ASP.NET 2.0은 .NET Framework 2.0에서 동작한다. 그리고 .NET Framework의 포괄적인 개념은 .NET이다. 따라서 다음과 같은 포함관계가 성립한다.

.NET > .NET Framework > ASP.NET

물론 윈도우 응용프로그램이라면 다음과 같은 포함관계도 성립한다.

.NET > .NET Framework > Windows Programming based C#

웹기술은 로그인의 처리에서 처럼, 웹서버에서 내부 사용되는 로직을 개발하고 동작되게 해주는 프로그래밍언어를 뜻한다. ASP.NET, JSP, PHP, ASP, Perl 등을 모두 웹 기술이라고 할 수 있다. 또한 웹 스크립트 언어라고도 부를 수 있다. ASP, JSP, PHP, Perl 등은 그 이름 자체를 스크립트 언어라도고 지칭할 수 있다. 하지만 ASP.NET 은 언어라고 할 수 없는 것이 ASP.NET을 구현할 수 있는 언어가 C#, VB, J#, C++ 등으로 나뉘어지기 때문에 ASP.NET은 웹 개발 기술이라고만 부른다.

ASP.NET의 장점은 다음과 같다.

• 강력한 캐싱 기능
• 강력한 개발도구 TOOL 제공
  Visual Studio는 웹, Windows, 콘솔 및 모바일 응용 프로그램까지 개발 할 수 있는 통합 개발 환경(IDE, Integrated Development Environment)이다. 각 ASP.NET의 버전별로 Visual Studio역시 다른 버전이 사용되고 있다.
  ASP.NET 1.0 → Visual Studio .NET 2002
  ASP.NET 1.1 → Visual Studio .NET 2003
  ASP.NET 2.0 → Visual Studio 2005 / Visual Studio 2008
• 유연성 : 웹사이트에의 개발 및 실행 시 발생될 수 있는 모든 문제에 대한 대처기능 제공되어있다.
• 언어독립적 협업 : 언어가 무엇이든 상관없는 것이 특징이다. 일부는 VB로 일부는 C#으로 구현하여 하나의 웹사이트로 동작시킬 수 있다.
• 개발의 단순성 : 인터페이스를 서버콘트롤로 제공, 도구상자이용
• 사이트 관리의 용이성
  Machine.config / Web.config 등으로 사이트를 쉽게 관리할 수 있다.
• 뛰어난 확장성 : 서버콘트롤을 상속받아 자신의 콘트롤을 만들어 서버콘트롤처럼 사용가능
• 보안기능
  인증(Authentication) / 권한 부여(Authorization) 를 쉽게할 수 있도록 도와준다. 이 역시 web.config를 사용하는 경우도 있다.

ASP.NET 구현환경

ASP.NET 1.x에서는 개발자들이 자신의 PC에 IIS 탑재가 가능한 Windows 또는 서버 급 Windows를 설치했다. VS 2005에서는 ASP.NET Development Server라는 내장 웹 서버를 제공하기 때문에 개발 PC의 Windows에 반드시 IIS가 탑재되어 있지 않아도 된다.

ASP.NET의 동작 원리

ASP.NET은 다음과 같이 동작한다.

웹 프로그래밍에서 가장 기본적인 구동 원리는 Request & Response이다.

ref : http://7day.tistory.com/38

요즈음 유니티 게임 포스팅만 하느라 안드로이드 강좌는 한참 손을 놓고 있었습니다.

이 강좌는 안드로이드 단말기와 서버와의 자료 및 정보 교환을 하는 방법에 대한 것이므로 잘 배워두면 곧바로 실무에 적용할 수 있을 것입니다.

단말기와 웹서버와 통신 방식은 다음과 같이 크게 두 가지로 구분할 수 있습니다. 

    ① HTTP 통신

    ② Socket 통신

HTTP와 Socket의 가장 큰 차이점은 접속(Connection)을 유지하는지의 여부입니다. 물론 파일 전송만을 전문으로 처리하는 FTP도 있지만 이것은 HTTP를 확장한 개념이므로 HTTP에 포함시키겠습니다.

1. HTTP 통신

HTTP 통신은 웹브라우저에 정보를 표시하는 것과 같이 클라이언트의 요청이 있을 때 서버가 해당 페이지에 대한 자료를 전송하고 곧바로 연결을 끊는 방식입니다. 현재 여러분이 제 블로그를 보고 있지만 맨 처음 이 페이지가 보여지는 순간만 서버와 연결되고 현재는 서버와 접속이 끊어진 상태입니다. 이 상태에서 F5 키를 눌러 새로고침을 하거나 다른 페이지로 이동하면 그때 다시 서버에 연결이 될 것입니다.

이렇게 하는 이유는 단 한가지. 서버의 부하를 줄여서 다른 접속을 원활하게 처리하기 위해서입니다. 여러분이 F5 키를 계속 누르거나 아예 F5 키에 연필을 꽂아서 클라이언트가 서버를 계속해서 물고 늘어지면 서버는 이 클라이언트의 연결을 유지하느라 다른 컴퓨터의 응답이 늦어질 것입니다. 이런 방식으로 여러 대의 PC가 서버를 붙잡고 늘어져서 서버가 다른 일을 하지 못하도록 하는 것을 DDOS 공격이라고 하죠...

2. Socket 통신

Socket 통신은 클라이언트가 서버와 접속이 되면 서버나 클라이언트에서 강제로 접속을 해제할 때까지는 계속해서 접속이 유지됩니다. 따라서 서버의 능력이 무한대가 아닌 이상 동시에 접속할 수 있는 클라이언트의 수가 제한이 될 수 밖에 없겠죠. 

Socket 통신은 실시간으로 정보 교환이 필요하는 채팅이나 온라인 게임, 실시간 동영상 강좌 등에 사용됩니다. 따라서 이와 같은 경우가 아니라면 서버와의 통신은 HTTP를 사용하는 것이 시스템의 자원을 보다 효과적으로 사용할 수 있습니다.

3. 시스템의 구성

단말기가 서버에 접속하기 위해서는 서버에 단말기의 응답을 처리하는 별도의 프로그램이 있어야 합니다. 저는 이것을 서버 모듈이라고 부르겠습니다. 서버 모듈은 C, PHP, Java, ASP 등 다양한 언어로 작성될 수 있을 것지만, 제가 사용하는 서버가 아파치 웹서버를 사용하므로 PHP로 구성하기로 합니다. 서버와 통신하기 위한 시스템의 구성은 다음 그림과 같습니다.

기본적인 개념을 세웠으므로 다음 강좌에서는 단말기 모듈과 서버 모듈을 설계하는 과정에 대해 알아보기로 하고 이번 강좌는 간단히 마무리합니다.

ref : http://foxmann.blog.me/90140923533