728x90
반응형

 

 

 

 

 

앱을 개발하다보면 Staging, Debug, Release 등에 따라 빌드를 다르게 해야하는 값들이 있습니다.

ex) api 의 base url

 

단순히 #if DEBUG 등 으로도 사용할 수 있겠지만 코드 수정없이 조건에 따라 다른 값을 설정할 수 있는 build configuration을 소개합니다.

 

 

Build Configurations

 

앱의 프로젝트 설정에 들어갑니다.

 

+를 누르면 어떤 설정을 복사할지 물어보는데 저는 Staging을 만들기 위해 Duplicate "Debug" Configuration 을 선택했습니다.

 

모두 Shared를 체크해줍니다.

 

 

Manage Schemes... 를 눌러줍니다.

 

기존의 schemes 를 duplicate 해줍니다. 이름은 앱 이름이 MyTestApp 이므로 MyTestApp-Staging 으로 지었습니다.

Debug용으로도 똑같이 duplicate 하고 이름을 지어줍니다.

 

 

 

 

각각 scheme 의 설정에서 Run의 Build Configuration을 해당하는 값으로 변경해줍니다.

(Test나 Analyze, Archive 등 다른 옵션도 필요하다면 변경해줍니다.)

 

이제 각 Build 별 값을 저장할 파일을 만들겠습니다.

New file 을 선택하고 Configuration Settings File 을 선택해서 생성합니다.

이때 Targets에 체크하면 안됩니다.

 

각 Build별 사용할 파일을 만듭니다.

 

각 파일에 key = value 의 형식으로 값을 작성합니다.

저는 예시로 BASE_URL 에 각 build name을 적었습니다.

 

이제 값들을 적용하기만 하면 사용할 수 있습니다.

다시 프로젝트 설정으로 돌아가서 Configurations로 갑니다.

Configurations의 각 Based on Configuration File 에 설정을 해줍니다.

 

이제 info.plist 설정을 해줘야합니다.

프로젝트 설정에서 TARGETS를 선택하고 Info에서 +를 눌러 추가해줍니다.

 

추가하면 다음과같이 Info.plist 파일이 생성되었을 것 입니다.

Key, Value 를 아까 입력한 key를 이용해서 다음과 같이 수정해줍니다.

 

이제 설정이 완료되었습니다.

방금 설정한 값은 아래의 코드로 불러올 수 있습니다.

Bundle.main.object(forInfoDictionaryKey: "BASE_URL") as? String ?? ""

 

 

 

 

완성

 

각각의 Scheme 로 실행해보면 같은 코드지만 configuration 에 의해 다른 값이 나오는 것을 볼 수 있습니다.

 

 

 

 

 

728x90
반응형
728x90
반응형

 

아마 일전에 코딩을 좀 배웠다 하시는 분들은 이미 Visual Studio community 가 깔려있을 겁니다.

 

이 글에서는 이미 깔려있는 Visual Studio community 와 Unity 를 연결하는 방법을 알려줍니다.

 

연결이 된건지 안된건지?

 

 

유니티에서 스크립트를 편집을 하기위해 창을 띄웠을 때 위의 그림과같이 MonoBehaviour 가 초록색으로 안나오면 연결이 안된 것입니다.

 

이때는 그냥 텍스트파일 열듯이 연 것이라서 자동완성 등 여러가지 기능을 지원하지 않습니다.

 

 

Unity 에서 설정

 

 

Edit - Preferences... 를 들어갑니다.

 

 

 

External Tools - External Script Editor 에서 Visual Studio 2019 를 선택해줍니다.

(Code 도 가능하긴 한데 Community 를 추천합니다)

 

 

만약 목록에 Visual Studio 2019가 없을 경우

 

 

Browse... 를 선택해줍니다.

 

 

 

Visual Studio 의 기본 설치 경로

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE

 

Visual Studio 의 설치경로로 가서 devenv.exe 를 선택해줍니다.

 

 

연결 완료

 

 

정상적으로 연결이 되있으면 위의 그림과 같이 MonoBehaviour 색깔이 초록색으로 나오고 유니티 연결 버튼이 있습니다.

 

 

728x90
반응형
728x90
반응형

 

 

TCP 패킷 구조

 

 

  • Source Port
    보내는 시스템의  애플리케이션 Port 입니다. 일반적으로 0 ~ 1023 까지는 예약되어있습니다.
    ex) HTTP(80)

  • Destination Port
    받는 시스템의 애플리케이션 Port 입니다. 위와 동일합니다.

  • Sequence Number
    패킷의 순서를 표시합니다.
    단위는 바이트로 표시되며 이 패킷이 데이터의 몇번째 바이트 부터인지를 나타냅니다.
    ex) 300byte 의 데이터를 100byte 씩 나눠서 보낼 때 첫 패킷은 0, 두번째는 100, 세번째는 200 이다.

  • Acknowledgement Number
    패킷을 받고 그에 대답을 할때 사용됩니다. 주로 패킷을 잘 수신 받았다는 대답과 같습니다.
    이전에 받은 Sequenc Number 의 다음 번호입니다.
    ex) 위의 예시와 같이 seq : 0 인 100byte 데이터를 수신하면 0~99byte 의 데이터를 받았으므로
         다음으로 필요한 100을 송신합니다.

  • Header length
    헤더의 길이가 가변이므로 총 헤더의 길이를 표시합니다. 단위는 바이트(byte)입니다.

  • Reserved
    현재는 사용되지않지만 미래를 위해 남겨둔 공간입니다.

  • Flags
    TCP 의 여러가지 속성들을 설정할 수 있는 비트들 입니다.

  • Window
    윈도우의 크기를 나타냅니다.
    윈도우란? 한번에 보낼 수 있는 최대 버퍼수를 말합니다.
    이 버퍼수에 따라 한번에 보내는 양이 정해지게됩니다.

  • Checksum
    error bit 검출을 위한 값입니다.

  • Urgent Pointer
    우선순위가 더 높은 데이터의 마지막 바이트 위치를 나타냅니다.

 

 

특징


TCP(Transmission Contrio Protocol)는 transport 계층에서 사용되는 대표적인 프로토콜입니다.

하위 계층인 IP와는 다르게 흐름제어(Flow control), 혼잡제어(Congestion control), 에러검출을 하기 때문에 신뢰성있는(reliable) 연결이 가능합니다. 따라서 신뢰성이 요구되는 에플리케이션에서 주로 사용합니다.

 

 

 

728x90
반응형
728x90
반응형

 

 

IPv6

 

 

IPv6 의 구조입니다.

 

  • Version
    IP 의 버전을 나타내는 값입니다. IPv6 이므로 6 가 들어있습니다.

  • DS
    IPv4 의 TOS 와 비슷합니다.
    이 패킷의 우선순위를 나타내는 값입니다. 이 값에 따라 패킷이 먼저 전송되거나 나중에 전송됩니다.
    이 값을 통해 QoS(Quality of Service) 를 구현하기 위해 사용됩니다.
    예를들어 실시간 인터넷 전화같은 경우 QoS가 만족되어야하므로 우선순위가 더 높을 것입니다.

  • ECN
    목적지 노드에게 현재 네트워크의 혼잡도를 알리는 값입니다.

  • Flow Label
    IP프로토콜을 연결 지향형으로 사용하기 위한 기능입니다.
    Src 부터 Dst 까지 패킷의 흐름을 나타냅니다.

  • Payload Length
    Payload (데이터) 의 길이입니다.
  • Next Header
    IPv4 의 Protocol 과 비슷합니다.
    IP 계층보다 더 상위 계층의 type 를 알려주는 값입니다.
    예로 ICMP(1), IGMP(2), TCP(6), UDP(17) 입니다.

  • Hop Limit
    IPv4 의 TTL 과 비슷합니다.
    네트워크 특성상 여러 AP 들을 거쳐서 패킷이 전달됩니다. 이렇게 AP를 하나 거칠때 마다 이 값이 1씩 떨어지고 0에 도달하게되면 패킷이 버려지게됩니다. 이 기능이 필요한 이유는 패킷이 전달되지 못하고 빙글빙글 돌거나 통신이 끊겼다면 네트워크내에 패킷이 계속 남게되는데 이런 현상을 막기위해 존재합니다.

  • Source IP Address
    출발지의 IP 주소값 입니다.

  • Destination IP Address
    도착지의 IP 주소값 입니다.

 

 

특징

 

IPv6 는 초창기 네트워크와는 다르게 멀티미디어를 많이 소비하는 현대 네트워크에 맞게 설게된 프로토콜입니다.
IPv4의 단점들을 보완하고, 연결지향적으로 바꾼게 바로 IPv6 입니다.

그래서 빠른 패킷처리를 위해 상당히 간단해졌습니다.

728x90
반응형
728x90
반응형

 

IPv4 의 패킷 구조

 

 

IPv4 의 구조입니다.

 

  • Version
    IP 의 버전을 나타내는 값입니다. IPv4 이므로 4 가 들어있습니다.

  • Header Length
    IPv4 는 Options 로 인해 헤더의 길이가 가변적입니다. 그래서 헤더길이를 적어줍니다.

  • Type of Service
    이 패킷의 우선순위를 나타내는 값입니다. 이 값에 따라 패킷이 먼저 전송되거나 나중에 전송됩니다.
    이 값을 통해 QoS(Quality of Service) 를 구현하기 위해 사용됩니다.
    예를들어 실시간 인터넷 전화같은 경우 QoS가 만족되어야하므로 우선순위가 더 높을 것입니다.

  • Total Length
    이 패킷의 총 길이입니다. Total Length - Header Length = Payload(데이터) Length 입니다. 

  • Identification
    통신중에 한번에 보낼 수 있는 데이터의 양을 넘으면 패킷이 단편화됩니다. 만약 단편화되었다면 이 값을 통해 패킷을 합칩니다. 단편화된 각 패킷이 같은 패킷에서 분할되었다면 같은 값을 가지고 있습니다.

  • Flags
    단편화가 일어났는지 확인하기위한 flag 값 입니다.

  • Fragment Offset
    단편화가 일어났을 경우 이 패킷이 몇번째인지를 나타내는 값입니다.

  • Time to Live (TTL)
    네트워크 특성상 여러 AP 들을 거쳐서 패킷이 전달됩니다. 이렇게 AP를 하나 거칠때 마다 이 값이 1씩 떨어지고 0에 도달하게되면 패킷이 버려지게됩니다. 이 기능이 필요한 이유는 패킷이 전달되지 못하고 빙글빙글 돌거나 통신이 끊겼다면 네트워크내에 패킷이 계속 남게되는데 이런 현상을 막기위해 존재합니다.

  • Protocol
    IP 계층보다 더 상위 계층의 type 를 알려주는 값입니다.
    예로 ICMP(1), IGMP(2), TCP(6), UDP(17) 입니다.

  • Header Checksum
    헤더의 오류검출을 위해 있는 값 입니다. 이 값을 통해 이 헤더가 통신중에 변조가 되었는지 확인할 수 있습니다.

  • Source IP Address
    출발지의 IP 주소값 입니다.

  • Destination IP Address
    도착지의 IP 주소값 입니다.

 

 

특징



IPv4 는 초기 네트워크를 위해 구현된 것 입니다. 그래서 현재 적용시키기에는 여러가지 문제가 있습니다.

  1. 헤더의 길이가 가변입니다.
    헤더의 길이가 가변이면 중간중간 라우터가 계산을 해줘야함을 의미합니다.

  2. 현대에는 필요없는 Checksum
    옛날 네트워크는 상당히 불안정한 상태였기때문에 패킷의 유실이나 변조가 잦았습니다. 그래서 다른 레이어 (TCP, UDP 등)에서 하는 오류검출을 IP 에서도 적용해서 오류검출을 해야 헀습니다. 그러나 통신이 발달하면서 현대의 네트워크는 유실이나 변조가 거의 없습니다. 그래서 불필요한 checksum 계산을 하게됩니다.
  3. 헤더가 전송중에 단편화가 될 수 있습니다.
    IPv4 는 전송중에 라우터의 MTU(최대 패킷 크기) 에 따라 단편화가 될 수 있습니다. 이 작업을 하게되면 그만큼 계산을 해야하며 여러 패킷으로 나눠져서 오버헤드가 됩니다.

  4. 점점 고갈되어가는 IP address
    현대로 오면서 인터넷에 연결되어있는 시스템은 매우 많아졌습니다. 그래서 32-bit 로 표현하기에는 점점 부족해지고 있습니다.

 

이런 많은 문제를 해결하기위해 나온것이 IPv6 입니다.

 

IPv6 에 관한 내용 >> 클릭 <<

728x90
반응형
728x90
반응형

 

TCP/IP 프로토콜은 1973년 빈트 서프에 의해 만들어진 프로토콜입니다.

 

현대 네트워크의 대부분의 패킷은 TCP/IP 프로토콜로 통신이 이루어지고 있습니다.

 

OSI 7 과는 조금 다르게 더 간결한 구조입니다.

 

 

TCP/IP

 

 

OSI 7 layer 와는 다르게 TCP/IP 는 4계층 밖에 없습니다. (Physical 은 보통 Network Access에 포함합니다)

 

  • Network Access
    OSI 7계층의 Physical 과 Datalink 계층을 합친것에 해당합니다.
    물리적인 주소로 MAC 을 이용해서 통신을 합니다.
    흔히 아는 LAN 카드가 이에 해당됩니다.

  • Internet Layer
    OSI 7계층의 Network 계층에 해당됩니다.
    논리적인 주소로 IP를 이용해서 통신합니다.
    노드간에 IP패킷을 전송하는 기능과 라우팅을 담당합니다.
    주로 IPv4, IPv6, ARM, RARP 같은 프로토콜이 이용됩니다.

  • Transport Layer
    OSI 7계층의 Transport 계층에 해당됩니다.
    노드간에 연결을 제어하고, 신뢰성을 보장합니다.
    포트를 통해 어떤 어플리케이션에게 정보를 전달할지 정합니다.
    주로 TCP, UDP 같은 프로토콜이 이용됩니다.

  • Application Layer
    OSI 7계층의 Session, Presentation, Application 에 해당됩니다.
    TCP/UDP 기반의 응용프로그램을 구현할 때 이용됩니다.
    주로 HTTP, FTP, SMTP 같은 프로토콜이 이용됩니다.

 

728x90
반응형
728x90
반응형

 

OSI 7 layer


OSI(Open system Interconnection) 7 계층은 국제표준화기구 (ISO) 에서 개발한 모델입니다.

현대에는 주로 TCP/IP 프토콜이 사용되고 개념만 남아있는 그런 것입니다.

 

 

OSI 7 계층은 이름대로 7개의 계층으로 나누어져있습니다.

 

  • Physical Layer
    말그대로 Physical 물리적인 계층입니다. 전파나 음파, 빛 등이 여기에 해당됩니다.

  • Datalink Layer
    Physical layer 를 통해 정보를 주고받는 계층입니다.
    이 계층에서는 에러검출, 재전송, 흐름제어를 하게됩니다.

  • Network Layer
    데이터를 목적지까지 전달하는 기능인 라우팅을 담당합니다.
    각 기기마다 주소(IP) 를 부여하며, 이 데이터를 어떻게 보낼지 경로를 설정하기도합니다.

  • Transport Layer
    응용프로그램에게 데이터가 가기 마지막 단계입니다.
    여러가지 데이터를 하나로 합쳐서 윗계층으로 보내줍니다.
    종단(end to end)통신을 하는 최하위 계층입니다.
    여기에서 QoS(서비스 품질) 를 위한 전송 우선순위나 다른 여러가지 기능도 수행합니다.

  • Session Layer
    흔히 아는 그 세션입니다. 네트워크상 양쪽의 연결을 관리, 지속시켜줍니다.
    세션을 만들고 유지, 종료, 전송 중단시 복구 기능이 있습니다.

  • Presentation Layer
    주로 데이터의 암호화/복호화가 이루어집니다.
    MIME 인코딩이나 이 데이터가 어떤 종류의 데이터인지 구분을 합니다.

  • Application Layer
    최종 단계의 계층입니다. 주로 흔히아는 HTTP, FTP, SMTP 등이 있습니다.
    우리가 주로 사용하는 인터넷 브라우저는 이러한 프로토콜의 사용을 도와주는 프로그램입니다.

 

 

구조

 

 

실제 통신시 위의 그림과같은 구조로 연결됩니다.

 

이번글에서는 OSI 7 layer 에 대해 알아보았습니다.

그러면 다음 글에서는 현대 통신의 주요 프로토콜인 TCP/IP 프로토콜에 대해 알아보겠습니다.

728x90
반응형
728x90
반응형

 

저번 글에서는 통신망이 어떻게 되어있는지에 대해 알아보았습니다.

이번 글에서는 네트워크의 구조에 대해 알아보겠습니다.

 

Layered Architecture


기본적으로 통신은 종단 간에 이루어집니다.

그리고 해당 종단의 프로그램 즉 애플리케이션에서 상대 애플리케이션으로 바로 보내지는 것이 아니라 하위 레이어들을 거쳐서 보내지게 됩니다.

 

 

예를 들어 어떤 회사의 사장이 다른 회사의 사장에게 문서를 보낸다고 칩시다.

이런 상황에서 사장이 직접 사장에게 문서를 보낼까요? 아닙니다.

당연히 사장 아래의 부하직원에게 명령을 내리고 해당 부하직원은 우체국에게 요청을 할 것입니다.

그리고 다시 우체국에서 상대 회사에 문서가 도착하면 해당 부하직원이 사장에게 전달할 것입니다.

 

이것과 같습니다. 컴퓨터에서도 똑같이 최상위 레이어인 애플리케이션에서 바로 상대 애플리케이션으로 데이터를 보내는 것이 아니라 하위 레이어로 차례대로 내려가서 도착하고 다시 상위 레이어로 올라갑니다.

 

이때 각 레이어가 지켜야 하는 규칙이 있습니다.

  1. 각 레이어는 다른 레이어와 독립적이어야 합니다.
  2. 각 레이어는 바로 밑 하위 레이어에 의존합니다.
  3. 각 레이어는 오직 바로 위 상위 레이어에게만 서비스를 제공합니다.

 

이러한 규칙들 덕분에 약간 비효율적으로 보일지는 몰라도 각 레이어별로 담당을 나눠서 집중할 수 있습니다.

 

 

Protocol

 

 

이때 이 구조를 보면 같은 레이어상에서 상대와 내가 마치 1대1로 통신을 하는 것 같이 보입니다.

이때 지켜야 하는 규칙을 프로토콜(Protocol) 이라고 합니다.

 

위의 예를 그대로 사용하면 사장과 사장끼리는 A회사 사장, B회사 사장이라고 부르고, 부하직원과 부하직원 사이에는 서로 상대의 부서와 이름으로 부를 것입니다. 그리고 우체국 간에는 서로를 주소로 부를 것 입니다.

 

이렇듯 각 레이어 간에는 반드시 protocol 을 지켜야 합니다.

 

 

 

이런 구조에서는 하위 레이어로 내려갈수록 해당 프로토콜의 정보 즉 헤더가 계속 앞에 붙게 됩니다.

이때 여러 가지 용어가 있습니다.

  • PDU (Protocol Data Unit
    PCI + SDU

  • SDU (Service Data Unit)
    Payload (데이터), 프로토콜의 서비스 대상

  • PCI (Protocol Control Information)
    프로토콜의 헤더입니다. 해당 프로토콜의 기능에 필요한 정보들이 들어있습니다.

 

그렇다면 이런 프로토콜에는 어떤 종류가 있을까요?

크게 2종류가 있는데 이것은 다음 글에서 알아보겠습니다.

 

728x90
반응형

+ Recent posts