반응형

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

반응형
반응형


Gsuite 에 가입한 후 도메인 설정 페이지로 어갑니다

Google 도메인을 통해 도메인 관리 

를 누르시고 그 안에 들어가면 종합 레코드란이 보일겁니다

이 부분에서 세팅 하면 됩니다




종합 레코드

시작하기 전에...

 

종합 레코드

종합 레코드는 Google Domains만의 고유한 개념으로서 G Suite와 통합하는 데 필요한 도메인 및 하위 도메인 매핑, 이메일 전달용 별칭 만들기, 도메인을 타사 웹 호스트와 통합하는 데 필요한 모든 리소스 레코드 추가와 같이 여러 리소스 레코드가 필요한 작업을 수행합니다. 일부 종합 레코드는 Google Domains의 DNS 탭 에서 직접 구성할 수 있습니다. 기타 종합 레코드는 웹 전달, 이메일 전달 또는 타사 웹 호스트 및 웹사이트 개발업체와의 통합을 설정할 때 Google Domains에서 자동으로 설정합니다.

DNS 탭 에서 직접 만들고 수정할 수 있는 종합 레코드는 다음과 같습니다.

  • App Engine - 하위 도메인이 Google App Engine에 호스팅된 앱을 가리키도록 합니다.
    참고: App Engine 종합 레코드는 더 이상 지원되지 않습니다. 기존 App Engine 종합 레코드가 있는 경우에는 아무 변화도 없습니다. App Engine 종합 레코드를 삭제할 수는 있지만 기타 방법으로 변경할 수는 없습니다.
    앞으로도 도메인을 Google App Engine와 통합할 수 있습니다. App Engine과 통합을 참조하세요.
  • 동적 DNS - 도메인 또는 하위 도메인이 동적으로 할당된 IP 주소가 포함된 레코드를 가리키도록 합니다(DNS 탭 에서 수정).
    도움이 필요하면 동적 DNS를 참조하세요.
  • G Suite - G Suite와 통합합니다(DNS 탭 에서 수정).
    도움이 필요하면 G Suite와 통합을 참조하세요.
  • 하위 도메인 전달 - 하위 도메인이 명명된 URL을 가리키도록 합니다(DNS 탭 에서 수정).
    도움이 필요하면 하위 도메인 전달을 참조하세요.

자동으로 설정되는 종합 레코드는 다음과 같습니다.

  • 이메일 전달 - 기존 이메일 주소로 전달되는 이메일 별칭을 만듭니다(이메일 탭 에서 수정). 이메일 전달을 참조하세요.
  • 웹 전달 - www 및 루트 도메인이 명명된 URL을 가리키도록 합니다(웹사이트 탭 에서 수정). 웹 전달을 참조하세요.
  • Shopify - 도메인을 Shopify에서 호스팅하는 사이트와 통합합니다(웹사이트 탭 에서 수정). 웹 인지도를 참조하세요.
  • Squarespace - 도메인을 Squarespace에서 호스팅하는 사이트와 통합합니다(웹사이트 탭 에서 수정). 웹 인지도를 참조하세요.
  • Weebly - 도메인을 Weebly에서 호스팅하는 사이트와 통합합니다(웹사이트 탭 에서 수정). 웹 인지도를 참조하세요.
  • Wix - 도메인을 Wix에서 호스팅하는 사이트와 통합합니다(웹사이트 탭 에서 수정). 웹 인지도를 참조하세요.

종합 레코드를 추가하는 방법은 다음과 같습니다.

  1. DNS 탭 에서 종합 레코드까지 아래로 스크롤합니다.
  2. App EngineG Suite 또는 하위 도메인 전달 레코드 유형을 선택합니다.
  3. 나머지 필드에 값을 입력하거나 원하는 G Suite 기능 및 하위 도메인을 선택하고 추가를 클릭합니다.

Google Domains에서 리소스 레코드 모음을 만들고 종합 레코드를 생성합니다.

각 종합 레코드 유형을 설정하는 방법은 다음을 참조하세요.

언제든지 종합 레코드 목록 옆의 삭제 또는 수정을 클릭하여 레코드를 변경하거나 삭제할 수 있습니다.



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


반응형
반응형
GitHub 를 대체할만한 무료 깃 레포지토리 서비스인 깃 랩에 대해서 간단히 알아봅시다.
(Git 사용법을 안다는 전제로 글을 적겠습니다)

가장 유명한 저장소인 깃허브(GitHub) 에는
대부분의 오픈소스 레포지토리가 올라가있고
각종 대기업들도 사용하며 많은 IDE(개발 도구)들에서 자체적으로 연동을 지원하기까지 합니다.

하지만 가장 큰 단점은,
내가 초대한 사람만 참여할 수 있는 비공개 레포지토리를 만들 경우
별도의 비용이 발생하게 된다는 점입니다.

그래서 지인의 추천으로 사용하게 된 것이 바로 깃랩(GitLab) 입니다.



깃랩에서는 비공개 레포지토리를 무료로 무제한 사용할 수 있습니다. (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

반응형
반응형
수퍼컴퓨터의 우수한 성능에도 불구하고 수퍼컴퓨터가 가지고 있는 보유 및 운영에 관한 단점을 해결하고자 하는 연구가 최근 수행되었는데, 그 중 하나가 클러스터(Cluster) 개념이다. 
클러스터란 여러 대의 컴퓨터를 네트워크를 통해 연결하여 하나의 단일 컴퓨터처럼 동작하도록 제작한 컴퓨터를 말한다. 클러스터는 병렬 컴퓨터의 일종으로 1994년경 NASA의 Goddard Space Flight Center에서 여러 대의 486 PC를 네트워크로 연결하여 제작한 컴퓨터가 베어울프 클러스터이다. 

클러스터는 사용 목적에 따라 구현 방법 및 소프트웨어가 달라지며, 클러스터의 기능과 운영이 달라진다. 따라서 클러스터는 그 사용 목적에 따라 과학 계산용 클러스터와 부하분산 클러스터로 나눌 수 있다. 과학 계산용 클러스터는 일반 범용컴퓨터로 계산하기 어려운 대규모 연산을 계산하는데 사용되고 있다. 예를 들어 기상 예측, 핵폭발 시뮬레이션, 유체역학, 입자의 분자 역학 시뮬레이션 등의 분야에 사용된다. 그러나 최근에는 클러스터 활용 범위가 넓어져서 이전에 수치 연산을 목적으로 사용되었던 클러스터를 3D 애니메이션 및 영화의 특수 효과에도 사용하고 있다. 
또한 과학 계산용 클러스터는 두 가지 형태로 구현될 수 있다. 
우선 모든 노드의 하드디스크에 독립적으로 운영체제를 모두 설치하여 각 노드가 시스템에 필요한 파일 및 라이브러리를 자체적으로 해결할 수 있도록 구성하는 방법이다. 
또 다른 방법은 서버 노드 한 대에만 하드디스크가 존재하여 다른 노드들은 서버 노드의 파일 시스템을 사용하는 diskless 클러스터 방법이 있다. 과학 계산용 클러스터를 사용하기 위해서 MPI(Message Passing Interface)나 PVM(Parallel Virtual Machine)과 같은 라이브러리를 사용하여 코딩한 프로그램을 사용해야 한다. 
이러한 라이브러리를 사용하는 이유는 클러스터내의 노드 수만큼 작업을 분할하여 네트워크를 통해 메시지를 전달함으로써 병렬처리가 가능하도록 하기 위해서이다. 

두 번째는 웹서버로 사용 가능한 부하분산 클러스터이다. 컴퓨터 네트워크 및 월드 와이드 웹(World Wide Web)의 발전으로 인터넷 사용자 및 웹서버의 숫자는 기하급수적으로 증가하고 있다. 
그러나 컴퓨터 네트워크의 발달에도 불구하고 웹서버에 접속하는 사용자 수가 많아짐에 따라 웹서버에 병목현상이 발생하고 있다.
예를 들어 동일 시간대에 한 웹서버에 접속하는 사용자 수가 많게 되면 웹서버는 과부하로 인하여 작동을 멈추거나 속도가 느려진다. 부하분산 클러스터는 단일 서버를 사용할 때 발생할 수 있는 부하를 다른 노드로 분산시켜 웹서버의 과부하를 해결할 수 있는 방법을 제공할 수 있다. 
부하분산 클러스터는 구현 방법에 따라 DR(Direct Routing), NAT(Network Address Translation) 등으로 구현할 수 있다. DR 방식은 클라이언트에 들어온 요청을 부하분산 서버가 다른 컴퓨터에 분배하고, 요청을 할당받은 컴퓨터가 직접 응답을 하는 방법이다. 
NAT 방식은 DR 방식과 비슷하지만 차이점은 클라이언트의 요청을 처리하는 컴퓨터는 응답을 부하분산 서버를 통해 목적지에 보내는 것이 다르며, NAT 방식과 DR 방식의 혼합된 형태로 구현하기도 한다.
그러나 부하분산 클러스터에서 부하분산 서버가 정지하거나 고장 발생의 경우 부하분산 클러스터가 작동을 멈추는 문제가 발생하게 된다.
이러한 문제점을 해결하는 방안으로 부하분산 서버를 감시하여 정지 및 고장 발생 시 클러스터 내의 다른 컴퓨터가 부하분산 서버 역할을 대신 할 수 있도록 하는 고가용성 클러스터가 함께 사용되기도 한다. 

동작 원리 : 클러스터로 구성된 컴퓨터가 수퍼컴퓨터와 대등한 성능을 발휘하기 위해서 여러 대의 컴퓨터가 단일 컴퓨터로 동작하도록 관리해야 하며, 각 노드간에 데이터 교환이 가능하도록 설정 해야한다. 
이러한 환경이 갖추어지면 어느 한 노드에서 다른 노드의 프로세스를 실행할 수 있도록 RSH(Remote Shell)이 작동할 수 있도록 해야 한다.
또한 MPI를 사용한 병렬 구조의 프로그램을 작성하여 실행시켜야 한다. 서버에서 병렬 프로그램을 실행하게 되면 MPI 데몬은 네트워크를 통해 각 노드로 작업을 분할하여 보내주며, 각 노드는 할당받은 작업을 처리하고 네트워크를 통해 결과를 서버에 돌려주게 된다. 
서버는 노드로부터 받은 결과를 조합하여 하나의 결과로 만들고 그 결과를 출력하게 된다. 예를 들어 4대의 노드로 구성된 클러스터에서 1부터 n까지 더하는 병렬 프로그램을 실행할 경우, 실행중인 MPI 데몬은 프로세스를 노드 수만큼 분할하여 각 노드에 작업을 할당하며, 작업을 할당받은 노드는 작업을 처리하여 결과를 서버에 돌려주고, 서버는 각 결과를 다시 조합하여 1에서 n까지 더한 결과를 출력하게 된다.
 
 


반응형
반응형

이글은 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는 데이터 엑세스 패턴과 저장 공간 이슈(로드의 적절한 분산 , 데이터의 균등한 저장)를 고려하여 적절한 샤드키를 결정하게 된다.


Horizontal Partitioning

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


Vertical Partitioning

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

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

반응형
반응형

on premise 사내 직접 설치


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

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




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

가장 큰 차이점은 기업내 구축형으로 사용할 것인지 클라우드 기반의 임대 서비스를 사용하느냐에 대한 구분이다.

Off-premises software (오프프레미스 소프트웨어)

오프프레미스 소프트웨어는 일반적으로 SaaS 또는 클라우드 컴퓨팅이라고 한다. 전통적인 방식의 온프레미스 소프트웨어와는 다르게 인터넷 네트워크에 연결 된 서버팜이나 클라우드의 원격 실행환경에서 사용되는 소프트웨어이다.


On-premises software (온프레미스 소프트웨어)

온프레미스 소프트웨어는 인터넷 네트워크에 연결 된 서버팜이나 클라우드 등의 원격 환경에서 사용하는 것이 아니라 건물에서 일하는 직원 또는 단체에서 설치, 실행하는 소프트웨어를 말한다. on-prem software(온프렘 소프트웨어) 또는 on-premise software(온프레미스 소프트웨어)라고 줄여서 쓰기도 하며 shrinkwrap software라고 부르기도 한다.

온프레미스 접근방식은 2005년까지 기업 소프트웨어 사용의 일반적인 접근방식이었기 때문에 이전 또는 전통적인 이라는 단어와 함께 사용된다. 


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는 시스템 예약)보다 큰 임의의 정수가 사용된다. 모든 연결은 유일 해야 한다.


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

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




소켓이란 무엇인가?

본 포스트는 오라클 자바 튜토리얼의 What Is a Socket?를 번역하였습니다.

소켓 통신

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

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

5connect5connect

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

6connect6connect

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

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

소켓의 정의

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

엔드 포인트란?

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

Socket 클래스

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

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

Web 통신

혹시 Web 통신을 하려고 한다면, URL 클래스와 관련 클래스(URLConnectionURLEncoder)들이 아마도 본 소켓 클래스보다 더 적당할 것입니다. 사실상, 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


반응형
반응형

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


이 비디오와 아래 정보는 하위 도메인이 무엇인지, 그리고 URL로 포워딩하거나 호스팅 계정 내의 IP 주소 및 디렉토리로 이동하도록 하기 위해 하위 도메인이 사용되는 방식에 대해 설명합니다.

 www.*******.com

서브도메인을 사용하여 사이트의 고유한 콘텐츠 영역을 위해 기억하기 쉬운 웹 주소를 쉽게 만들 수 있습니다. www.coolexample.com/pics 뿐 아니라 URL pics.coolexample.com을 통해서 접속할 수 있는 "pics"라는 사이트의 사진을 위한 서브도메인을 만들 수 있습니다.

도메인 이름당 최대 100개의 서브도메인을 추가할 수 있습니다. 서브도메인에 여러 단계를 추가할 수도 있습니다. 예를 들어, 사이트의 흥미로운 영역을 보다 구체적으로 다루기 위해 info.blog.coolexample.com을 추가할 수 있습니다. 각각의 서브도메인의 길이는 최대 25자입니다.



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  파일로 저장합니다. 



호스트 (네트워크)


네트워크 호스트(network host)는 컴퓨터 네트워크에 연결된 컴퓨터나 기타 장치이다. 네트워크 호스트는 정보 리소스, 서비스, 애플리케이션을 네트워크 상의 사용자나 기타 노드에 제공할 수 있다. 네트워크 호스트는 네트워크 주소가 할당된 네트워크 노드이다.

서버와 호스트

모든 서버는 호스트이지만 모든 호스트가 서버인 것은 아니다. 네트워크에 연결이 확립된 모든 장치는 호스트의 자격이 있는 반면, 다른 장치(클라이언트)로부터의 연결을 수락하는 호스트만 서버가 될 수 있다.

개념의 기원

운영 체제에서 터미널 호스트라는 용어는 전통적으로 서비스를 컴퓨터 터미널에 제공하는 다중 사용자 컴퓨터나 소프트웨어, 또는 서비스를 소형이거나 기능이 떨어지는 장치[1]에 제공하는 컴퓨터(예: 텔레타입 터미널이나 비디오 터미널을 서비스하는 메인프레임 컴퓨터)를 가리킨다. 그 밖의 예로는 텔넷 호스트(텔넷 서버)와 xhost(X 윈도 클라이언트)를 들 수 있다.

문서는 통신 네트워크에 연결되는 범용 목적의 컴퓨터 시스템으로서 호스트를 정의한다. (운영 체제에 참여하는 리소스를 달성하는 목적)[2]




포트 (컴퓨터 네트워킹)


인터넷 프로토콜 스위트에서 포트(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

일반적인 포트 번호

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

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

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




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)

반응형
반응형




JSON(제이슨[1]JavaScript Object Notation)은 속성-값 쌍( attribute–value pairs and array data types (or any other serializable value))으로 이루어진 데이터 오브젝트를 전달하기 위해 인간이 읽을 수 있는 텍스트를 사용하는 개방형 표준 포맷이다. 비동기 브라우저/서버 통신 (AJAX)을 위해, 넓게는 XML(AJAX가 사용)을 대체하는 주요 데이터 포맷이다. 특히, 인터넷에서 자료를 주고 받을 때 그 자료를 표현하는 방법으로 알려져 있다. 자료의 종류에 큰 제한은 없으며, 특히 컴퓨터 프로그램의 변수값을 표현하는 데 적합하다.

본래는 자바스크립트 언어로부터 파생되어 자바스크립트의 구문 형식을 따르지만 언어 독립형 데이터 포맷이다. 즉, 프로그래밍 언어나 플랫폼에 독립적이므로, 구문 분석 및 JSON 데이터 생성을 위한 코드는 CC++C#자바자바스크립트파이썬 등 수많은 프로그래밍 언어에서 쉽게 이용할 수 있다.

JSON 포맷은 본래 더글라스 크록포드가 규정하였다. RFC 7159와 ECMA-404라는 두 개의 경쟁 표준에 의해 기술되고 있다. ECMA 표준은 문법만 정의할 정도로 최소한으로만 정의되어 있는 반면 RFC는 시맨틱, 보안적 고려 사항을 일부 제공하기도 한다.[2] JSON의 공식 인터넷 미디어 타입은 application/json이며, JSON의 파일 확장자는 .json이다.

자료형과 문법


기본 자료형

JSON의 기본 자료형은 다음과 같다:

수(Number)

기본 자료형의 수는 다음과 같이 표현된다. C나 자바에서의 8진수와 16진수를 표현하는 방법은 지원되지 않는다.

  • 정수
74
1974
750
-114
-273
3.14
-2.718
1e4
2.5e12
3.4e+4
4.56e-8
5.67E+10
6.78E-5

문자열(String)

항상 큰 따옴표(")로 묶어야 하며, 그 안에는 유니코드 문자들이 나열된다. 유니코드 중 역슬래시(\)와 큰따옴표(")는 바로 사용할 수 없다. 역슬래시는 제어문자를 표현하기 위해 사용되며 다음과 같은 의미를 지닌다.

\b 백스페이스
\f 폼 피드
\n 개행
\r 캐리지 리턴
\t 탭
\" 따옴표
\/ 슬래시
\\ 역슬래시
\uHHHH 16진수 네자리로되어 있는 유니코드 문자
"1234"
"Love"
"O-matic"
"한글"
"\"JSON\""

배열(Array)

배열은 대괄호[]로 나타낸다. 배열의 각 요소는 기본 자료형이거나 배열, 객체이다. 각 요소들은 쉼표(,)로 구별된다. 각 요소가 나타나는 순서에 의미가 있다.

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

객체(Object)

객체는 이름/값 쌍의 집합으로, 중괄호{}를 사용한다. 이름은 문자열이기 때문에 반드시 따옴표를 하며, 값은 기본 자료형이다. 각 쌍들은 쉼표(,)로 구별된다. 각 쌍이 나오는 순서는 의미가 없다.

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

JSON 메시지 단위는 배열이나 객체이다. 위의 두 예는 JSON 메시지가 될 수 있다.

예제

다음은 한 사람에 관한 정보를 갖는 JSON 객체이다.

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

장점

  • JSON은 텍스트로 이루어져 있으므로, 사람과 기계 모두 읽고 쓰기 쉽다.
  • 프로그래밍 언어와 플랫폼에 독립적이므로, 서로 다른 시스템간에 객체를 교환하기에 좋다.
  • 자바스크립트의 문법을 채용했기 때문에, 자바스크립트에서 eval 명령으로 곧바로 사용할 수 있다. 이런 특성은 자바스크립트를 자주 사용하는 웹 환경에서 유리하다. 그러나 실질적으로 eval 명령을 사용하면 외부에서 악성 코드가 유입될 수 있다. 모질라 파이어폭스 3.5, 인터넷 익스플로러 8, 오페라 10.5, 사파리구글 크롬 등 대부분의 최신 웹 브라우저는 JSON 전용 파서 기능을 내장하고 있으므로 이런 기능을 사용하는 것이 더 안전할 뿐만 아니라 빠른 방법이다.




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

반응형

'서버(Server) > 인터넷과 개념' 카테고리의 다른 글

정적 웹 페이지, 동적 웹 페이지  (0) 2018.05.12
호스트(Host) 와 포트(Port)  (0) 2018.05.10
what's JSON?  (0) 2018.05.04
ASP.NET의 정의  (0) 2018.04.16
HTTP vs Socket 통신차이  (0) 2018.04.12
반응형

 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

서버-클라이언트 구준

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


.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



반응형

+ Recent posts